कारोसेल लोडिंग पर फ्रंट-एंड मेमोरी उपयोग में 30 गुना सुधार

2020 की दूसरी तिमाही में, हमने एक्सपीरियंस पेज पर एक टेक रिफैक्टर किया, जिसमें इसे React में फिर से लिखा गया और REST API का उपयोग किया गया। लेकिन कार्यान्वयन के दौरान, हमें एक दिलचस्प समस्या मिली।

एक्सपीरियंस पेज पर लगभग 20 कैरोसेल हैं, जिनमें से प्रत्येक में कम से कम 60 टाइलें हैं। इसलिए पेज 1,200 से अधिक एक्सपीरियंस रेंडर करेगा, जिसमें उनकी जानकारी जैसे कि शीर्षक, उपयोगकर्ता रेटिंग, एक साथ उपयोगकर्ता, और थंबनेल शामिल हैं। प्रत्येक कैरोसेल में, दाईं ओर स्क्रॉल करने पर यदि और एक्सपीरियंस हैं तो उन्हें लोड करने के लिए एक अनुरोध भेजा जाएगा। फिर अनुरोध से प्राप्त नए डेटा को कैरोसेल में जोड़ दिया जाएगा, जिसका अर्थ है कि DOM में और नोड्स जुड़ेंगे और ब्राउज़र में और थंबनेल रेंडर होंगे। जैसे-जैसे उपयोगकर्ता और डेटा अनुरोध करने के लिए स्क्रॉल करेंगे, ब्राउज़र के अंदर मेमोरी का उपयोग बढ़ेगा, और फिर UX धीमा हो जाएगा और लैग होने लगेगा।

मेमोरी प्रोफ़ाइल

हम इस समस्या का प्रोफाइल करने के लिए Chrome डेवलपर टूल्स का उपयोग कर सकते हैं। पहला स्नैपशॉट पेज के प्रारंभिक लोड होने पर लिया जाता है, और दूसरा तब लिया जाता है जब उपयोगकर्ता एक कैरोसेल में अगले स्क्रॉल पर 12 बार क्लिक करता है। हम 100+ स्ट्रिंग नोड्स और बढ़े हुए थंबनेल रेंडरिंग के कारण मेमोरी उपयोग में लगभग 9.7MB की वृद्धि देखते हैं।

समाधान

जब कैरोसेल स्क्रॉल होता है, तो उपयोगकर्ता केवल कैरोसेल विंडो से आइटम देखते हैं। उदाहरण के लिए, 1920×1080 रिज़ॉल्यूशन वाले लैपटॉप में, फुल स्क्रीन ब्राउज़र के तहत, हर बार केवल ~9 आइटम ही दिखाई देंगे। इसलिए, सभी अदृश्य नोड्स और थंबनेल को एक साथ रेंडर करना या अनुरोध से लौटा गया अधिक डेटा DOM में ले जाना अनावश्यक है।

तो, आइडिया यह है: पहली बार API अनुरोध से कच्चा डेटा प्राप्त करने के बाद, हम DOM में रेंडरिंग के लिए तैयारी करते हुए समान लंबाई की एक ऐरे बनाते हैं। रेंडरिंग ऐरे के अंदर, हम डिस्प्ले को भरने और अगले पर स्क्रॉल करने के लिए पर्याप्त डेटा ही भर सकते हैं। ऐरे का बाकी हिस्सा तब ही भरा जाएगा जब डिस्प्ले विंडो उसके करीब स्क्रॉल की जाएगी। रेंडरिंग डेटा की रेंज को रिकॉर्ड करने के लिए आइए दो इंडेक्स रखें: रेंडरिंगस्टार्टइंडेक्स और रेंडरिंगएंडइंडेक्स। हम यह बताने के लिए एक कर्सर सेट करते हैं कि सूची में कौन सी शुरुआती पोजीशन दिखाई दे रही है। स्क्रॉलिंग के दौरान, हमें कर्सर को पहले दिखाई देने वाले आइटम के इंडेक्स पर लगातार अपडेट करना होगा। स्क्रॉलिंग एनिमेशन समाप्त होने से पहले, हमें यह जांचना होगा कि अगला कर्सर रेंडरिंग डेटा एरे के अंदर है या नहीं। कारोसेल विंडो के आकार और कार्ड के आकार के अनुसार, हम आसानी से बता सकते हैं कि डिस्प्ले विंडो में कितनी दृश्यमान वस्तुएँ फिट होंगी। फिर, हमें यह सुनिश्चित करने की आवश्यकता है कि वर्तमान विंडो और अगली विंडो की वस्तुएँ रेंडरिंग डेटा एरे की सीमा के अंदर हों। यदि नहीं, तो हम खाली सूची को भरने के लिए कच्चे डेटा से वस्तुएँ लेते हैं और साथ ही कर्सर स्थिति से पहले के डेटा को भी साफ़ कर देते हैं। यह तब लागू होगा जब उपयोगकर्ता दाईं या बाईं ओर स्क्रॉल करते हैं। जब उपयोगकर्ता दाईं ओर स्क्रॉल करते हैं, तो बैकग्राउंड में अधिक डेटा प्राप्त करके, हम हर बार नया डेटा प्राप्त करने के बाद कच्चे डेटा को भर देंगे। हालांकि, कच्चा डेटा पेज रेंडरिंग में शामिल नहीं होगा।

मेमोरी प्रोफ़ाइल

आइए फिर से Chrome डेवलपर टूल्स पर नज़र डालें। पहले की तरह, पहला स्नैपशॉट इनिशियलाइज़ होने पर लिया जाता है और दूसरा 12 बार दाईं ओर स्क्रॉल करने के बाद लिया जाता है। अब, 100+ आइटम लोड करने में केवल 0.3MB अतिरिक्त मेमोरी लगती है, जबकि पहले यह 9.7MB थी।

अगला क्या?

कारोसेल घटक को बड़ी डेटा विंडो को संभालने के लिए बेहतर बनाने के अलावा, जब हम किसी फ़ीचर/पेज को रिफ़ैक्टर करते हैं, तो हमें प्रदर्शन जानकारी प्राप्त करने के लिए और बेंचमार्क जोड़ने की आवश्यकता होती है।

हालाँकि आधुनिक वेब एप्लिकेशन स्टैक फ्रंट-एंड की ओर बढ़ रहा है, फ्रंट-एंड टेलीमेट्री को कैप्चर करना और उसमें सुधार करना पारंपरिक बैक-एंड टेलीमेट्री जितना ही महत्वपूर्ण है।