प्रॉडक्ट की ज़्यादा जानकारी वाले पेजों को ऑप्टिमाइज़ किया गया, ताकि Lighthouse में ज़्यादा से ज़्यादा एफ़आईडी में 90% की कमी आए और Chrome उपयोगकर्ता अनुभव रिपोर्ट में एफ़आईडी में 9% की बढ़ोतरी हो.
Mercado Libre, लैटिन अमेरिका का सबसे बड़ा ई-कॉमर्स और पेमेंट नेटवर्क है. यह 18 देशों में उपलब्ध है. साथ ही, ब्राज़ील, मेक्सिको, और अर्जेंटीना में यह यूनीक विज़िटर और पेज व्यू के आधार पर, मार्केट लीडर है.
कंपनी लंबे समय से वेब परफ़ॉर्मेंस पर फ़ोकस कर रही है. हालांकि, उन्होंने हाल ही में एक टीम बनाई है, ताकि वे साइट की परफ़ॉर्मेंस पर नज़र रख सकें और साइट के अलग-अलग हिस्सों को ऑप्टिमाइज़ कर सकें.
इस लेख में, Mercado Libre की फ़्रंटएंड आर्किटेक्चर टीम के गिल पाज़, पावलो कारमिनैटी, और ओलेघ बुर्खाय के काम के बारे में बताया गया है. इन लोगों ने Core Web Vitals में से एक मेट्रिक, फ़र्स्ट इनपुट डेले (एफ़आईडी) और उसके लैब प्रॉक्सी, कुल ब्लॉकिंग समय (टीबीटी) को ऑप्टिमाइज़ करने के लिए काम किया है.
90%
Lighthouse में ज़्यादा से ज़्यादा संभावित एफ़आईडी में कमी
9%
ज़्यादा उपयोगकर्ताओं को CrUX में एफ़आईडी "तेज़" के तौर पर दिख रहा है
लंबे समय तक चलने वाले टास्क, फ़र्स्ट इनपुट डिले, और टोटल ब्लॉकिंग टाइम
महंगा JavaScript कोड चलाने से ज़्यादा समय लेने वाले टास्क हो सकते हैं. ये ऐसे टास्क होते हैं जो ब्राउज़र के मुख्य थ्रेड में 50 एमएस से ज़्यादा समय तक चलते हैं.
एफ़आईडी (फ़र्स्ट इनपुट डिले), उपयोगकर्ता के किसी पेज से इंटरैक्ट करने (उदाहरण के लिए, किसी लिंक पर क्लिक करने) से लेकर, ब्राउज़र के उस इंटरैक्शन के जवाब में इवेंट हैंडलर को प्रोसेस करने में लगने वाले समय को मेज़र करता है. ज़्यादा समय लेने वाले JavaScript कोड को लागू करने वाली साइट पर, कई लंबे टास्क हो सकते हैं. इनसे एफ़आईडी पर बुरा असर पड़ता है.
उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, यह ज़रूरी है कि साइटों का पहला इनपुट डिले 100
मिलीसेकंड से कम हो:
Mercado Libre की साइट ज़्यादातर सेक्शन में अच्छी परफ़ॉर्म कर रही थी. हालांकि, उन्हें Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट में पता चला कि प्रॉडक्ट की जानकारी वाले पेजों का एफ़आईडी खराब था. इस जानकारी के आधार पर, उन्होंने साइट पर प्रॉडक्ट पेजों के लिए इंटरैक्टिविटी को बेहतर बनाने पर ध्यान देने का फ़ैसला किया.
इन पेजों पर उपयोगकर्ता, जटिल इंटरैक्शन कर सकते हैं. इसलिए, हमारा मकसद अहम फ़ंक्शन में रुकावट डाले बिना, इंटरैक्टिविटी को ऑप्टिमाइज़ करना था.
प्रॉडक्ट की जानकारी वाले पेजों पर इंटरैक्टिविटी को मेज़र करना
एफ़आईडी के लिए किसी असल उपयोगकर्ता की ज़रूरत होती है. इसलिए, इसे लैब में मेज़र नहीं किया जा सकता. हालांकि, कुल ब्लॉकिंग समय (टीबीटी) मेट्रिक को लैब में मेज़र किया जा सकता है. यह फ़ील्ड में एफ़आईडी के साथ अच्छी तरह से जुड़ी होती है. साथ ही, इंटरैक्टिविटी पर असर डालने वाली समस्याओं को भी कैप्चर करती है.
उदाहरण के लिए, नीचे दिए गए ट्रेस में, मुख्य थ्रेड पर टास्क चलाने में 560 मिलीसेकंड का कुल समय लगा, लेकिन उसमें से सिर्फ़ 345 मिलीसेकंड को कुल ब्लॉकिंग समय माना गया. यह समय, हर उस टास्क के हिस्सों का कुल योग होता है जो 50 मिलीसेकंड से ज़्यादा का होता है:
Mercado Libre ने लैब में टीबीटी को प्रॉक्सी मेट्रिक के तौर पर इस्तेमाल किया, ताकि असल दुनिया में प्रॉडक्ट की जानकारी देने वाले पेजों की इंटरैक्टिविटी को मेज़र और बेहतर किया जा सके.
उन्होंने यह तरीका अपनाया:
- WebPageTest का इस्तेमाल करके, यह पता लगाएं कि असली डिवाइस पर मुख्य थ्रेड को कौनसी स्क्रिप्ट व्यस्त रख रही थीं.
- सबसे ज़्यादा संभावित फ़र्स्ट इनपुट डिले (सबसे ज़्यादा संभावित एफ़आईडी) में हुए बदलावों के असर का पता लगाने के लिए, Lighthouse का इस्तेमाल करें.
लंबे टास्क को विज़ुअलाइज़ करने के लिए, WebPageTest का इस्तेमाल करना
WebPageTest (WPT) एक वेब परफ़ॉर्मेंस टूल है. इसकी मदद से, दुनिया भर की अलग-अलग जगहों पर असली डिवाइसों पर टेस्ट चलाए जा सकते हैं.
Mercado Libre ने अपने उपयोगकर्ताओं के अनुभव को फिर से बनाने के लिए, WPT का इस्तेमाल किया. इसके लिए, उन्होंने असल उपयोगकर्ताओं की तरह ही डिवाइस टाइप और जगह चुनी. खास तौर पर, उन्होंने Moto 4G डिवाइस और डॉल्स, वर्जीनिया को चुना, क्योंकि उन्हें मेक्सिको में Mercado Libre के उपयोगकर्ताओं के अनुभव का अनुमान लगाना था. WPT के मुख्य थ्रेड व्यू को देखकर, Mercado Libre को पता चला कि लगातार कई लंबे टास्क, मुख्य थ्रेड को दो सेकंड के लिए ब्लॉक कर रहे थे:
उससे जुड़े वॉटरफ़ॉल का विश्लेषण करने पर, उन्हें पता चला कि उन दो सेकंड का ज़्यादातर हिस्सा, उनके आंकड़ों के मॉड्यूल से आया था. ऐप्लिकेशन का मुख्य बंडल साइज़ बड़ा (950 केबी) था. साथ ही, उसे पार्स, कंपाइल, और एक्ज़ीक्यूट करने में काफ़ी समय लगा.
ज़्यादा से ज़्यादा संभावित एफ़आईडी का पता लगाने के लिए, Lighthouse का इस्तेमाल करना
Lighthouse की मदद से, अलग-अलग डिवाइसों और जगहों में से किसी एक को नहीं चुना जा सकता. हालांकि, यह साइटों की परफ़ॉर्मेंस का पता लगाने और परफ़ॉर्मेंस से जुड़े सुझाव पाने के लिए काफ़ी मददगार टूल है.
प्रॉडक्ट की जानकारी वाले पेजों पर Lighthouse का इस्तेमाल करते समय, Mercado Libre को पता चला कि ज़्यादा से ज़्यादा संभावित एफ़आईडी, लाल रंग में मार्क की गई एकमात्र मेट्रिक थी. इसकी वैल्यू 1710 मिलीसेकंड थी.
इस आधार पर, Mercado Libre ने Lighthouse और WebPageTest जैसे प्रयोगशाला टूल में, अपने ज़्यादा से ज़्यादा संभावित एफ़आईडी स्कोर को बेहतर बनाने का लक्ष्य तय किया. ऐसा इस उम्मीद के साथ किया गया कि इन सुधारों से उनके असली उपयोगकर्ताओं पर असर पड़ेगा और इसलिए, ये Chrome उपयोगकर्ता अनुभव रिपोर्ट जैसे असली उपयोगकर्ताओं को मॉनिटर करने वाले टूल में दिखेंगे.
लंबे समय तक चलने वाले टास्क ऑप्टिमाइज़ करना
पहला आइटरेशन
मुख्य थ्रेड ट्रेस के आधार पर, Mercado Libre ने उन दो मॉड्यूल को ऑप्टिमाइज़ करने का लक्ष्य सेट किया जो महंगा कोड चला रहे थे.
उन्होंने इंटरनल ट्रैकिंग मॉड्यूल की परफ़ॉर्मेंस को ऑप्टिमाइज़ करना शुरू किया. इस मॉड्यूल में, सीपीयू पर ज़्यादा लोड डालने वाला एक ऐसा टास्क था जो मॉड्यूल के काम करने के लिए ज़रूरी नहीं था. इसलिए, इसे सुरक्षित तरीके से हटाया जा सकता था. इससे पूरी साइट के लिए, JavaScript में 2% की कमी आई.
इसके बाद, उन्होंने बंडल के सामान्य साइज़ को बेहतर बनाने पर काम करना शुरू किया:
Mercado Libre ने ऑप्टिमाइज़ेशन के अवसरों का पता लगाने के लिए, webpack-bundle-analyzer का इस्तेमाल किया:
- शुरुआत में, उन्हें पूरे Lodash मॉड्यूल की ज़रूरत थी. इसे हर-तरीके की ज़रूरत के साथ बदल दिया गया था, ताकि पूरी लाइब्रेरी के बजाय, Lodash का सिर्फ़ एक सबसेट लोड किया जा सके. साथ ही, Lodash को और भी छोटा करने के लिए, lodash-webpack-plugin के साथ इसका इस्तेमाल किया गया था.
उन्होंने Babel के ये ऑप्टिमाइज़ेशन भी लागू किए:
- पूरे कोड में Babel के हेल्पर का फिर से इस्तेमाल करने और बंडल का साइज़ काफ़ी कम करने के लिए, @babel/plugin-transform-runtime का इस्तेमाल करना.
- मुख्य बंडल में मौजूद बड़ी कॉन्फ़िगरेशन फ़ाइल को हटाने के लिए, बिल्ड के समय टोकन बदलने के लिए babel-plugin-search-and-replace का इस्तेमाल करना.
- प्रोप टाइप हटाकर कुछ अतिरिक्त बाइट बचाने के लिए, babel-plugin-transform-react-remove-prop-types जोड़ना.
इन ऑप्टिमाइज़ेशन की वजह से, बंडल का साइज़ लगभग 16% कम हो गया.
असर का आकलन करना
इन बदलावों की वजह से, Mercado Libre के लगातार होने वाले लंबे टास्क दो सेकंड से घटकर एक सेकंड हो गए:
Lighthouse ने सबसे ज़्यादा संभावित फ़र्स्ट इनपुट डिले में 57% की कमी दिखाई:
दूसरा इटरेशन
टीम ने लंबे समय तक चलने वाले टास्क पर काम करना जारी रखा, ताकि बाद में सुधार किए जा सकें.
इस जानकारी के आधार पर, उन्होंने ये बदलाव लागू करने का फ़ैसला लिया:
- मुख्य बंडल का साइज़ कम करते रहें, ताकि कॉम्पाइल और पार्स करने में लगने वाला समय ऑप्टिमाइज़ किया जा सके. उदाहरण के लिए, अलग-अलग मॉड्यूल में डुप्लीकेट डिपेंडेंसी हटाकर.
- JavaScript को छोटे-छोटे हिस्सों में बांटने और अलग-अलग कॉम्पोनेंट को बेहतर तरीके से लोड करने के लिए, कॉम्पोनेंट लेवल पर कोड को अलग-अलग करने की सुविधा लागू करें.
- कॉम्पोनेंट को हाइड्रेट करने की प्रोसेस को बाद में शुरू करें, ताकि मुख्य थ्रेड का बेहतर तरीके से इस्तेमाल किया जा सके. इस तकनीक को आम तौर पर कुछ हद तक हाइड्रेशन कहा जाता है.
असर का आकलन करना
इससे मिलने वाले WebPageTest ट्रेस में, JS एक्सीक्यूशन के छोटे-छोटे हिस्से भी दिखे:
साथ ही, Lighthouse में उनके ज़्यादा से ज़्यादा संभावित एफ़आईडी का समय 60%और कम हो गया:
असली उपयोगकर्ताओं के लिए प्रोग्रेस को विज़ुअलाइज़ करना
WebPageTest और Lighthouse जैसे प्रयोगशाला टेस्टिंग टूल, डेवलपमेंट के दौरान समाधानों को बेहतर बनाने के लिए बहुत अच्छे हैं. हालांकि, असल लक्ष्य असल उपयोगकर्ताओं के अनुभव को बेहतर बनाना है.
Chrome उपयोगकर्ता अनुभव रिपोर्ट में, उपयोगकर्ता अनुभव से जुड़ी मेट्रिक की ऐसी जानकारी मिलती है जिससे यह पता चलता है कि असल दुनिया में Chrome का इस्तेमाल करने वाले उपयोगकर्ताओं को वेब पर मौजूद लोकप्रिय साइटों पर कैसा अनुभव मिल रहा है. BigQuery में क्वेरी चलाकर, PageSpeedInsights या CrUX API की मदद से, रिपोर्ट का डेटा पाया जा सकता है.
CrUX डैशबोर्ड की मदद से, मुख्य मेट्रिक की प्रोग्रेस को आसानी से देखा जा सकता है:
अगले चरण
वेब की परफ़ॉर्मेंस को बेहतर बनाने का काम कभी खत्म नहीं होता. Mercado Libre को पता है कि इन ऑप्टिमाइज़ेशन से, उनके उपयोगकर्ताओं को क्या फ़ायदा मिलता है. वे साइट पर कई ऑप्टिमाइज़ेशन लागू करते रहते हैं. इनमें प्रॉडक्ट लिस्टिंग पेजों पर प्रीफ़ेच करना, इमेज ऑप्टिमाइज़ेशन वगैरह शामिल हैं. साथ ही, वे प्रॉडक्ट लिस्टिंग पेजों में सुधार करते रहते हैं, ताकि ब्लॉक होने का कुल समय (टीबीटी) और प्रॉक्सी एफ़आईडी को और भी कम किया जा सके. इन ऑप्टिमाइज़ेशन में ये शामिल हैं:
- कोड को अलग-अलग हिस्सों में बांटने के समाधान पर काम करना.
- तीसरे पक्ष की स्क्रिप्ट को बेहतर तरीके से लागू करना.
- बंडलर लेवल (webpack) पर ऐसेट बंडलिंग में लगातार सुधार किए जा रहे हैं.
Mercado Libre के पास परफ़ॉर्मेंस की पूरी जानकारी है. इसलिए, वे साइट में इंटरैक्टिविटी को ऑप्टिमाइज़ करते रहे हैं. साथ ही, उन्होंने Core Web Vitals की मौजूदा दो अन्य मेट्रिक: एलसीपी (सबसे बड़े कॉन्टेंटफ़ुल पेंट) और सीएलएस (कुल लेआउट शिफ़्ट) को और बेहतर बनाने के अवसरों का आकलन करना शुरू कर दिया है.