कारोसेल लोड करताना फ्रंट-एंड मेमरी वापर 30 पट सुधारणे

२०२० च्या दुसऱ्या तिमाहीत, आम्ही अनुभव पृष्ठावर तंत्रज्ञान पुनर्रचना केली, React मध्ये पुन्हा लिहून आणि REST API वापरून. परंतु अंमलबजावणी दरम्यान, आम्हाला एक मनोरंजक समस्या आढळली.

अनुभवांच्या पृष्ठावर सुमारे 20 कॅरोसेल्स आहेत, प्रत्येकामध्ये किमान 60 टाइल्स आहेत. त्यामुळे, पृष्ठ 1,200 पेक्षा जास्त अनुभवांचे रेंडरिंग करेल, ज्यात त्यांचा शीर्षक, वापरकर्ता रेटिंग, एकाच वेळी असलेले वापरकर्ते आणि थंबनेल यांसारखी संबंधित माहिती समाविष्ट असेल. प्रत्येक कॅरोसेलमध्ये, उजवीकडे स्क्रोल केल्यावर पुढील अनुभवांचा संच लोड करण्यासाठी विनंती पाठवली जाईल, जर आणखी अनुभव असतील तर. नंतर त्या विनंतीमुळे मिळालेला नवीन डेटा कॅरूसेलमध्ये जोडला जातो, म्हणजे DOM मध्ये अधिक नोड्स जोडले जातात आणि ब्राउझरमध्ये अधिक थंबनेल्स रेंडर होतात. वापरकर्ते अधिक डेटा मागवण्यासाठी स्क्रोल केल्यावर ब्राउझरमधील मेमरी वापर वाढतो, आणि त्यामुळे UX मंदावतो व लॅग होऊ लागतो.

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

आम्ही Chrome Developer Tools वापरून या समस्येचे प्रोफाइल करू शकतो. पहिला स्नॅपशॉट पृष्ठ प्रथम लोड होताच घेतला जातो, आणि दुसरा स्नॅपशॉट वापरकर्त्याने एका कॅरूसेलमध्ये पुढील स्क्रोल 12 वेळा क्लिक केल्यानंतर घेतला जातो. आम्हाला 100+ स्ट्रिंग नोड्स आणि वाढलेल्या थंबनेल रेंडरिंगमुळे मेमरी वापरात सुमारे 9.7MB वाढ दिसते.

समाधान

जेव्हा कॅरोसेल स्क्रोल होते, तेव्हा वापरकर्ते फक्त कॅरोसेल विंडोमधील आयटमच पाहतात. उदाहरणार्थ, 1920×1080 रिझोल्यूशनच्या लॅपटॉपवर पूर्ण स्क्रीन ब्राउझरमध्ये प्रत्येक वेळी सुमारे 9 आयटमच दिसतात. त्यामुळे सर्व अदृश्य नोड्स आणि थंबनेल्स एकत्र रेंडर करण्याची किंवा रिक्वेस्टमधून परत आलेल्या अतिरिक्त डेटाला DOM मध्ये समाविष्ट करण्याची गरज नाही.

तर, कल्पना अशी आहे: API विनंतीमधून कच्चा डेटा प्रथमच मिळवल्यानंतर, DOM मध्ये रेंडरिंगसाठी त्याच लांबीची अ‍ॅरे तयार करतो. रेंडरिंग अ‍ॅरेमध्ये, डिस्प्ले भरण्यासाठी आणि पुढच्या भागात स्क्रोल करण्यासाठी पुरेसा डेटाच भरतो. अ‍ॅरेचा उर्वरित भाग तेव्हाच भरला जाईल जेव्हा डिस्प्ले विंडो त्याजवळ स्क्रोल होईल. रेंडरिंग डेटाच्या श्रेणीला नोंदवण्यासाठी आपण दोन निर्देशांक ठेवूया: renderingStartIndex आणि renderingEndIndex. यादीत कोणती प्रारंभिक स्थिती दृश्यमान आहे हे सांगण्यासाठी आपण एक कर्सर सेट करतो. स्क्रोल करताना, आपल्याला सतत कर्सरला पहिल्या दृश्यमान आयटमच्या निर्देशांकावर अपडेट करावे लागेल. स्क्रोलिंग अॅनिमेशन पूर्ण होण्यापूर्वी, पुढील कर्सर रेंडरिंग डेटा अॅरेच्या आत आहे का हे तपासावे लागेल. कारोसेल विंडोच्या आकार आणि कार्डच्या आकारावरून, डिस्प्ले विंडोमध्ये किती दृश्यमान आयटम बसतील हे आपण सहज सांगू शकतो. नंतर, सध्याच्या विंडोमधील आणि पुढील विंडोमधील आयटम रेन्डर्ینگ डेटा अॅरेच्या श्रेणीत आहेत याची आपण खात्री करावी. जर तसे नसेल, तर आम्ही कच्च्या डेटातून आयटम घेऊन रिकामी यादी भरतो आणि त्याच वेळी कर्सरच्या स्थितीपूर्वीचा डेटा मिटवतो. हे वापरकर्ते उजवीकडे किंवा डावीकडे स्क्रोल केल्यावर लागू होईल. जेव्हा वापरकर्ते उजवीकडे स्क्रोल करतात, तेव्हा पार्श्वभूमीत अधिक डेटा मिळवून प्रत्येक वेळी नवीन डेटा प्राप्त झाल्यानंतर आम्ही कच्चा डेटा भरतो. तथापि, कच्चा डेटा पृष्ठ रेंडरिंगमध्ये समाविष्ट होणार नाही.

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

चला पुन्हा Chrome Developer Tools पाहूया. पूर्वीप्रमाणेच, पहिली स्नॅपशॉट इनिशियलायझेशनच्या वेळी घेतली जाते आणि दुसरी उजवीकडे 12 वेळा स्क्रोल केल्यानंतर घेतली जाते. आता 100+ आयटम लोड केल्यावर वाढलेली मेमरी फक्त 0.3MB आहे, पूर्वीच्या 9.7MB च्या तुलनेत.

पुढे काय?

कारोसेल घटकाला मोठ्या डेटा विंडो हाताळण्यासाठी सुधारणा करण्याबरोबरच, जेव्हा आपण एखादे फीचर/पृष्ठ रिफॅक्टर करता, तेव्हा कामगिरीची माहिती मिळवण्यासाठी अधिक बेंचमार्क जोडणे आवश्यक असते.

जरी आधुनिक वेब अनुप्रयोग स्टॅक फ्रंट-एंडकडे वळत असला तरी, फ्रंट-एंड टेलिमेट्री कॅप्चर करणे आणि सुधारणा करणे पारंपारिक बॅक-एंड टेलिमेट्रीइतकेच महत्त्वाचे आहे.