GoDaddy में किए गए बदलावों की एक केस स्टडी, जिसे लाखों साइटों की वेबसाइट की परफ़ॉर्मेंस को बेहतर बनाने के लिए लागू किया गया है. इससे उन्हें PageSpeed Insights और वेबसाइट की परफ़ॉर्मेंस की जानकारी का अच्छा स्कोर पाने में मदद मिली है.
GoDaddy, दुनिया भर के उद्यमियों के लिए दुनिया का सबसे बड़ा सेवाओं का प्लैटफ़ॉर्म है. हम 2 करोड़ से ज़्यादा ग्राहकों और हर जगह के उद्यमियों से जुड़े अपने वैश्विक समुदाय को सशक्त बनाने के एक मिशन पर हैं. हम उन्हें ऑनलाइन आगे बढ़ने के लिए ज़रूरी सभी सहायता और टूल देकर — उन्हें सक्षम बनाना चाहते हैं.
साल 2019 में, GoDaddy ने वेबसाइट और मार्केटिंग की सुविधा लॉन्च की. इसका मकसद, ऐसे टूल और सेवाएं उपलब्ध कराना था जो इस्तेमाल में आसान हों और कारोबार के मालिकों को अपने लक्ष्य हासिल करने में मदद करते हों. वेबसाइटें और मार्केटिंग, वेबसाइट बनाने के साथ-साथ मार्केटिंग और ई-कॉमर्स टूल को इंटिग्रेट करती हैं. साथ ही, इन्हें बेहतरीन सलाह देती हैं, ताकि ग्राहक अपने नए कारोबारों को सफल बना सकें.
वेबसाइट + मार्केटिंग के लॉन्च होने के बाद से ही, परफ़ॉर्मेंस प्रॉडक्ट का एक अहम हिस्सा रही है. यह कुछ ऐसा रहा है जिसकी निगरानी की जाती है और उस पर लगातार काम किया जाता रहा है. इस लेख में, हम GoDaddy की लैब परफ़ॉर्मेंस टेस्टिंग से लेकर वेबसाइट की परफ़ॉर्मेंस की जानकारी की मदद से, असल दुनिया के डेटा का इस्तेमाल करने तक के सफ़र की समीक्षा करेंगे. साथ ही, हम प्रॉडक्ट में किए गए सुधारों की सीरीज़ के बारे में भी जानेंगे, ताकि हमारे ग्राहक की साइटों का पास रेट बहुत ज़्यादा हो.
Lighthouse की मदद से परफ़ॉर्मेंस ट्रैक करना
हमने परफ़ॉर्मेंस ट्रैक करने के लिए, लाइटहाउस डेटा का इस्तेमाल किया है. जब भी प्लैटफ़ॉर्म पर कोई वेबसाइट पब्लिश की जाती है, तो हम "Lighthouse4u" नाम के अपने इंटरनल टूल का इस्तेमाल करके उसकी परफ़ॉर्मेंस को मापते हैं. यह टूल https://github.com/godaddy/lighthouse4u के तौर पर Google Lighthouse उपलब्ध कराता है. इससे हमें पता चला कि लैब सेटिंग में साइटें आम तौर पर कैसा परफ़ॉर्म कर रही हैं.
हम अपने प्लैटफ़ॉर्म पर लाखों साइटों को होस्ट करते हैं. इसलिए, उनमें कई तरह की सुविधाएं और कॉन्टेंट होता है. इसलिए, यह ज़रूरी था कि हम टेस्ट की जा रही हर साइट के मेटाडेटा के साथ परफ़ॉर्मेंस डेटा को जोड़ें. जैसे, इस्तेमाल किए गए टेंप्लेट, रेंडर किए गए विजेट का टाइप वगैरह. इससे हमें पता चला कि वेबसाइट की किन सुविधाओं की परफ़ॉर्मेंस अच्छी नहीं थी. साथ ही, इससे हमें यह जानकारी भी मिली कि सुधार की ज़रूरत कहां है.
उदाहरण के लिए, इससे हमें यह पता चल पाया कि "पॉप-अप मॉडल" का पेज की स्पीड पर खराब असर पड़ रहा था. इस सुविधा का इस्तेमाल करने वाली साइटों की परफ़ॉर्मेंस, बिना पेज की तुलना में 12 पॉइंट कम रही. JavaScript को लोड होने से रोकने के लिए कोड में अपडेट करने के बाद, हमने अपने लाइटहाउस स्कोर में 2 पॉइंट का सुधार किया. इस जानकारी को "कुकी बैनर" जैसी अन्य सुविधाओं पर लागू किया जा सका, जो पेज लोड होने के तुरंत बाद रेंडर होता है.
सुविधाओं के आधार पर, समस्या वाली साइटों को देखने के साथ-साथ, हमने अपने JavaScript बंडल का विश्लेषण किया. हमने पाया कि इसके साइज़ का एक बड़ा हिस्सा बाहरी डिपेंडेंसी (imम्यूटable.js और ड्राफ़्ट.js) से आता है. हमने मांग के हिसाब से लेज़ी लोड डिपेंडेंसी के लिए उपभोक्ताओं को फिर से तैयार करके, बंडल के साइज़ को कम कर दिया है. इससे JavaScript बंडल के सामान्य साइज़ में 50% से ज़्यादा की गिरावट हुई, जो 200 केबी से बढ़कर करीब 90 केबी (कम से कम) हो गया. बंडल का साइज़ छोटा होने की वजह से, ब्राउज़र बाहरी एसेट लोड कर सकता था. साथ ही, साइट के लोड होने की शुरुआती लाइफ़साइकल से पहले, ज़रूरी स्क्रिप्ट लागू कर पाता था. इससे सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) और फ़र्स्ट इनपुट डिले (एफ़आईडी) में बढ़ोतरी होती थी.
हमारी लगातार कोशिशों की वजह से, नवंबर 2020 में साइट के लाइटहाउस का औसत स्कोर 40 पॉइंट से बढ़कर मई 2021 में 70 पॉइंट से ज़्यादा हो गया. हालांकि, हमारी सभी कोशिशें कामयाब नहीं हुईं. कई बार हम हैरान रह गए, जब स्थानीय जांच के नतीजों और फ़ील्ड में जांच के नतीजे हमेशा एक जैसे नहीं थे. लैब के नतीजे बहुत मददगार साबित हुए थे, लेकिन यह फ़ील्ड से जुड़े असली उपयोगकर्ता अनुभवों पर ध्यान देने का समय था.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी की मदद से, उपयोगकर्ताओं का असल डेटा ट्रैक करना
अपने ग्राहकों की साइटों में web-vitals लाइब्रेरी जोड़ने के बाद, हम वेबसाइट पर आने वाले लोगों के असल डिवाइसों का डेटा माप पाए. इस डेटा में, हार्डवेयर, नेटवर्क की स्पीड, और उपयोगकर्ता के इंटरैक्शन (जैसे कि स्क्रोल करना या क्लिक करना) मेट्रिक, लाइटहाउस की लैब सेटिंग के बराबर नहीं होती. यह सही दिशा में एक बड़ा कदम था, क्योंकि अब हमारे पास ऐसा डेटा है जिससे हमें पता चलता है कि हमारी वेबसाइट पर आने वाले लोगों को कैसा अनुभव मिल रहा था.
सबसे कमज़ोर लिंक पर फ़ोकस करना: लेआउट शिफ़्ट (सीएलएस) करना
नए डेटा का विश्लेषण करने से हमें इस बारे में एक नया नज़रिया मिला कि वेबसाइट की गति को बेहतर बनाने के लिए क्या किया जाना चाहिए. लाइटहाउस स्कोर को बेहतर करने के लिए किए गए काम की वजह से, हमारा 75वां पर्सेंटाइल एलसीपी 860 मि॰से॰ था और हमारा एफ़आईडी 10 मि॰से॰ से कम था. इसलिए, हमें अपने ग्राहक की साइटों पर इन मेट्रिक की पास रेट ज़्यादा रही: 78% और 98%. हालांकि, कुल लेआउट शिफ़्ट (सीएलएस) के नंबर, लाइटहाउस में इस्तेमाल किए जाने वाले लेआउट से काफ़ी अलग दिखते हैं. 75वें पर्सेंटाइल पर हमारा सीएलएस, 0.17 से ज़्यादा था, जो "पास" करने के लिए 0.1 थ्रेशोल्ड से ज़्यादा था. इस तरह, पास होने की दर, हमारी सभी साइटों के मुकाबले सिर्फ़ 47% थी.
इस मेट्रिक से, हमारा कुल पास रेट 40% तक नीचे गया. इसलिए, हमने अगस्त 2021 के आखिर तक इस संख्या को 60% से ज़्यादा करने का लक्ष्य तय किया. ऐसा करने के लिए, हमें सीएलएस पर ध्यान देना होगा.
असल ज़िंदगी में, लोग पेज के साथ इंटरैक्ट करते हैं और "पेज के ऊपरी हिस्से" में मौजूद कॉन्टेंट को स्क्रोल करते हैं. यह ऐसी चीज़ है जिसे वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी बेहतर तरीके से कैप्चर करती है. साइट के शुरुआत में लोड होने के दौरान लोग उसके साथ कैसे इंटरैक्ट करते हैं, इसमें काफ़ी बदलाव होने की वजह से सीएलएस, लैब और फ़ील्ड डेटा से अलग होता है.
वेबसाइट की परफ़ॉर्मेंस की मेट्रिक के थ्रेशोल्ड को हासिल करने का तरीका
परफ़ॉर्मेंस में सुधार करने के लिए कभी-कभी कोशिश करनी पड़ती है और कुछ गड़बड़ी हुई है. साथ ही, हर बार कोशिश करने पर यह काम नहीं करता. हालांकि, यहां कुछ सुधार बताए गए हैं जिनसे हमें अपने लक्ष्यों को हासिल करने में मदद मिली है.
इमेज लोड करने के लिए जगह रिज़र्व करने से हमारा सीएलएस स्कोर काफ़ी बेहतर हो गया, क्योंकि यह इमेज के नीचे मौजूद कॉन्टेंट की जगह नहीं बदलता. हमने सीएसएस aspect-ratio प्रॉपर्टी का इस्तेमाल करके, इस समस्या को उन ब्राउज़र पर ठीक किया है जिन पर यह सुविधा काम करती है. जो स्क्रीन मौजूद नहीं हैं उनके लिए हमने एक पारदर्शी प्लेसहोल्डर इमेज लोड की, जिसे कैश मेमोरी में सेव किया गया था और उसका साइज़ कुछ बाइट था. इस तरह हम तुरंत लोड हो जाते थे.
इमेज के इस सामान्य व्यवहार की मदद से हम सर्वर साइड रेंडरिंग के दौरान, व्यूपोर्ट की चौड़ाई और इमेज के आसपेक्ट रेशियो के आधार पर, इमेज की आखिरी ऊंचाई का पहले से हिसाब लगा सकते हैं. इसकी वजह से एचटीएमएल मार्कअप को फ़ाइनल इमेज के लिए वर्टिकल स्पेस के साथ रिज़र्व रखा गया. यह सुधार खास तौर पर मोबाइल डिवाइस पर देखने लायक था, क्योंकि इमेज को मोबाइल व्यूपोर्ट के पूरे फैलाव के लिए रेंडर किया जाता है.
हमारे ग्राहकों की साइटों पर मौजूद कुछ कॉम्पोनेंट में डाइनैमिक कॉन्टेंट होता है. जैसे, बाहरी खरीदारों से मिली समीक्षाओं की सूची. इन्हें सर्वर साइड रेंडरिंग से फ़ायदा पाने के लिए, पूरी तरह सीएसएस में नहीं बदला जा सकता. लेआउट शिफ़्ट को बेहतर बनाना मुश्किल होता है, क्योंकि कॉन्टेंट (इस तरह लंबाई) अलग-अलग होता है. उन मामलों में, हमने हर एक खास कॉम्पोनेंट की औसत ऊंचाई की निगरानी के आधार पर, पहले से तय किए गए min-height को एक कंटेनर में रैप किया था. इनर डाइनैमिक कॉम्पोनेंट रेंडर होने के बाद, min-height को हटा दिया जाता है. यह समाधान बिलकुल सटीक नहीं था, लेकिन इस समाधान की मदद से हम लेआउट शिफ़्ट को काफ़ी कम कर पाए.
सीएलएस में सुधार पर ध्यान देते हुए, हमने एलसीपी पर काम करना जारी रखा. कई वेबसाइटों पर, एलसीपी में इमेज की समस्या सबसे बड़ी होती है और हमारे लिए इसे सुधारना बेहद ज़रूरी है. हमने IntersectionObserver का इस्तेमाल करके, लेज़ी लोड वाली इमेज में सुधार किए. हालांकि, हमने महसूस किया कि हर ब्रेकपॉइंट (मोबाइल, टैबलेट, डेस्कटॉप, बड़े डेस्कटॉप) के लिए इमेज का साइज़ सही तरीके से सेट नहीं था. इसलिए, हमने इमेज जनरेट करने वाले कोड को अपडेट किया, ताकि हर ब्रेकपॉइंट के हिसाब से इमेज को क्लैंप और स्केल किया जा सके. इसके बाद, पिक्सल डेंसिटी के आधार पर रिज़ॉल्यूशन को फिर से बढ़ाया जा सके. उदाहरण के लिए, इससे बड़ी इमेज का साइज़ 192 केबी से घटाकर 102 केबी कर दिया गया.
खराब इंटरनेट कनेक्शन वाले डिवाइसों पर वेबसाइटों को तुरंत रेंडर करने के लिए, हमने कनेक्शन स्पीड के आधार पर इमेज क्वालिटी को डाइनैमिक तौर पर कम करने के लिए कोड जोड़ा है. ऐसा करने के लिए, navigator.connection से मिली downlink प्रॉपर्टी का इस्तेमाल करें. हम यूआरएल पर आधारित क्वेरी पैरामीटर लागू करते हैं, ताकि उन नेटवर्क स्थितियों के आधार पर हमारे एसेट एपीआई से इमेज की क्वालिटी कम की जा सके.
हमारी ग्राहक साइटों के कई सेक्शन डायनैमिक तौर पर लोड होते हैं. हम जानते हैं कि किसी साइट के पब्लिश होने पर उस पर कौनसे सेक्शन रेंडर होंगे. इसलिए, हमने कनेक्शन और ज़रूरी हैंडशेक शुरू करने से पहले ही, rel=preconnect रिसॉर्स हिंट का इस्तेमाल किया. हम फ़ॉन्ट और अन्य ज़रूरी संसाधनों को तेज़ी से लोड करने के लिए, रिसॉर्स से जुड़े संकेतों का भी इस्तेमाल करते हैं.
अपनी साइटें बनाते समय, ग्राहक अलग-अलग तरह की सुविधाएं देने के लिए, कई ऐसे सेक्शन जोड़ते हैं जिनमें इनलाइन स्क्रिप्ट हो सकती हैं. पूरे एचटीएमएल पेज पर इन स्क्रिप्ट का इनलाइन होना, परफ़ॉर्मेंस के लिए हमेशा बेहतर नहीं होता. हमने इन स्क्रिप्ट को बाहरी ब्राउज़र में दिखाने का फ़ैसला किया, ताकि ब्राउज़र, स्क्रिप्ट के कॉन्टेंट को एसिंक्रोनस तरीके से लोड और पार्स कर सके. बाहरी तौर पर बनाई गई नई स्क्रिप्ट को भी सभी पेजों पर शेयर किया जा सकता है. इससे ब्राउज़र और सीडीएन कैश मेमोरी में डेटा की परफ़ॉर्मेंस बेहतर हो सकती है. हमने ज़रूरी स्क्रिप्ट को इन-लाइन रखा, ताकि ब्राउज़र उन्हें तेज़ी से पार्स और एक्ज़ीक्यूट कर सके.
नतीजे
सीएलएस पर फ़ोकस करने से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक का पास रेट 40% से बढ़कर करीब 70% हो गया. अब इसमें 75% की बढ़ोतरी हुई है!
जब लोग हमारे प्लैटफ़ॉर्म पर अपडेट करने और अपनी साइटों को फिर से पब्लिश करने के लिए वापस आते हैं, तब उनकी परफ़ॉर्मेंस में हुए नए सुधार होते हैं. इसकी वजह से, "वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली परफ़ॉर्मेंस को पास करने वाली" साइटों की संख्या लगातार बढ़ रही है, जैसा कि यहां दिए गए चार्ट में दिखाया गया है:
मीटिंग में सामने आए नतीजे
परफ़ॉर्मेंस को बेहतर बनाने के लिए ज़रूरी क्षेत्रों का पता लगाना और प्रोग्रेस को ट्रैक करना, इस बात पर निर्भर करता है कि मेज़रमेंट के लिए कौनसे टूल का इस्तेमाल किया जाता है. लाइटहाउस किसी "लैब सेटिंग" में, वेबपेज के ऊपरी हिस्से की परफ़ॉर्मेंस को मेज़र करने के लिए मददगार था. हालांकि, यह सिर्फ़ उपयोगकर्ता के इंटरैक्शन (जैसे कि पेज स्क्रोल करना) से होने वाली परफ़ॉर्मेंस की समस्याओं को सटीक तरीके से कैप्चर नहीं करता.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को मेटाडेटा के साथ ट्रैक करने से, हमें अपनी सेवाओं में किए गए सुधारों को देखने, उन्हें टारगेट करने, और उनके असर को मापने में मदद मिली. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक के स्कोर में सुधार करने की वजह से, टीम को हमारे सभी कोडबेस में मौजूद खराब परफ़ॉर्मेंस वाले पैटर्न की पहचान करने और उन्हें बदलने में मदद मिली. कभी-कभी उम्मीद के मुताबिक बदलाव करने का असर हमारी उम्मीद के मुताबिक नहीं होता है. हालांकि, बाकी बार बदलाव सही नहीं हुआ. यह कोई अनोखी दुनिया नहीं है, इसलिए आपको कोशिश करते रहना होगा.