कुछ ही महीनों में, यूके की मुख्य समाचार वेबसाइट अपने 75वें पर्सेंटाइल सीएलएस को 250% बढ़ाकर, 0.25 से 0.1 करने में कामयाब रही.
विज़ुअल स्टैबिलिटी चैलेंज
लेआउट शिफ़्ट से आपको परेशानी हो सकती है. Telegraph Media Group (TMG) में विज़ुअल स्टैबिलिटी बहुत ज़रूरी है क्योंकि लोग मुख्य रूप से समाचार देखने के लिए हमारे ऐप्लिकेशन का इस्तेमाल करते हैं. अगर किसी लेख को पढ़ते समय लेआउट बदल जाता है, तो हो सकता है कि पाठक उस लेख से अपनी जगह खो दे. यह परेशान और ध्यान भटकाने वाला हो सकता है.
इंजीनियरिंग के नज़रिए से यह पक्का करना मुश्किल हो सकता है कि पेज शिफ़्ट न हों और पाठक के काम में रुकावट न आए. खास तौर पर तब, जब आपके ऐप्लिकेशन के कुछ हिस्से एसिंक्रोनस रूप से लोड होते हैं और पेज पर डाइनैमिक रूप से जोड़े जाते हैं.
TMG में, हमारी कई टीमें कोड क्लाइंट-साइड का योगदान देती हैं:
- मुख्य इंजीनियरिंग. कॉन्टेंट को बेहतर बनाने के लिए तीसरे पक्ष के समाधानों को लागू करना, जैसे कि कॉन्टेंट के सुझाव देना और टिप्पणी करना.
- मार्केटिंग. A/B टेस्ट करके पता लगाना कि हमारे पाठक नई सुविधाओं या बदलावों से कैसे इंटरैक्ट करते हैं.
- विज्ञापन. विज्ञापन के अनुरोधों को मैनेज करना और प्री-बिडिंग वाले विज्ञापन को मैनेज करना.
- एडिटोरियल. ट्वीट या वीडियो जैसे लेखों के साथ-साथ कस्टम विजेट (जैसे, कोरोना वायरस केस ट्रैकर) में कोड एम्बेड करना.
यह पक्का करना मुश्किल हो सकता है कि इन टीमों में पेज का लेआउट कमज़ोर न हो. कुल लेआउट शिफ़्ट की मेट्रिक का इस्तेमाल करके, यह पता लगाया गया कि हमारे पाठकों के लिए ऐसा कितनी बार होता है. इससे टीम को, उपयोगकर्ता अनुभव के बारे में ज़्यादा अहम जानकारी मिली. साथ ही, टीम को ऐसा करने का एक अच्छा लक्ष्य भी मिला. इससे हमारा 75वां पर्सेंटाइल सीएलएस, 0.25 से बढ़कर 0.1 हो गया और पासिंग बकेट 57% से बढ़कर 72% हो गई.
250%
सीएलएस में 75वां पर्सेंटाइल सुधार
15%
अच्छे सीएलएस स्कोर वाले ज़्यादा उपयोगकर्ता
हमने शुरुआत कहां से की थी
CrUX डैशबोर्ड की मदद से, हम यह पता लगा पाए कि पेजों पर हमारी उम्मीद से ज़्यादा बार बदलाव हो रहा था.
आम तौर पर, हम चाहते थे कि हमारे कम से कम 75% पाठकों को "अच्छा" अनुभव मिले. इसलिए, हमने लेआउट में गड़बड़ी की वजहों का पता लगाना शुरू किया.
हम लेआउट शिफ़्ट को कैसे मेज़र करते हैं
लेआउट शिफ़्ट होने की वजह जानने के लिए, हमने Chrome DevTools और WebPageTest का इस्तेमाल किया है. DevTools में, हमने परफ़ॉर्मेंस टैब के अनुभव सेक्शन का इस्तेमाल किया है, ताकि लेआउट शिफ़्ट होने के अलग-अलग इंस्टेंस को हाइलाइट किया जा सके. साथ ही, यह भी पता लगाया जा सके कि पूरे स्कोर में उनका योगदान कैसे रहा.
WebPageTest यह हाइलाइट करता है कि "लेआउट शिफ़्ट हाइलाइट करें" चुनने पर, टाइमलाइन व्यू में लेआउट में कहां बदलाव होता है.
सबसे ज़्यादा देखे गए टेंप्लेट में हर शिफ़्ट की समीक्षा करने के बाद, हम आपके लिए ऐसे आइडिया लाए हैं जिन्हें बेहतर बनाने के तरीके बताए गए हैं.
लेआउट शिफ़्ट को कम किया जा रहा है
हमने उन चार चीज़ों पर ध्यान दिया जिनमें लेआउट शिफ़्ट कम किया जा सकता है: - विज्ञापन - इमेज - हेडर - एम्बेड
विज्ञापन
विज्ञापनों को JavaScript के ज़रिए शुरुआती पेंट के बाद लोड किया जाता है. उन्होंने जो कंटेनर लोड किए उनमें से कुछ की ऊंचाई पहले से तय नहीं थी.
हालांकि, हमें सही ऊंचाई नहीं पता, लेकिन स्लॉट में लोड किए गए सबसे सामान्य विज्ञापन आकार का इस्तेमाल करके जगह बुक की जा सकती है.
कुछ मामलों में हमने विज्ञापन की औसत ऊंचाई को गलत समझा. टैबलेट रीडर के लिए, स्लॉट छोटा हो रहा था.
हमने स्लॉट दोबारा देखा और सबसे सामान्य साइज़ का इस्तेमाल करने के लिए, ऊंचाई को अडजस्ट किया.
इमेज
वेबसाइट पर कई इमेज लेज़ी लोड होती हैं और उनके लिए जगह बनाई जाती है.
हालांकि, लेखों में सबसे ऊपर दी गई इनलाइन इमेज में कंटेनर में कोई स्पेस नहीं था और न ही उसमें टैग से जुड़ी चौड़ाई और ऊंचाई वाले एट्रिब्यूट थे. इस वजह से, लेआउट के लोड होने के दौरान वह शिफ़्ट हो गया.
इमेज में सिर्फ़ चौड़ाई और ऊंचाई एट्रिब्यूट जोड़ने से, यह पक्का हो गया है कि लेआउट शिफ़्ट नहीं हुआ.
हेडर
हेडर, मार्कअप में कॉन्टेंट के नीचे था और उसे सीएसएस का इस्तेमाल करके सबसे ऊपर रखा गया था. मूल आइडिया था, नेविगेशन से पहले कॉन्टेंट लोड होने को प्राथमिकता देना. हालांकि, इस वजह से पेज में कुछ समय के लिए बदलाव आया.
हेडर को मार्कअप के ऊपर ले जाने से पेज इस शिफ़्ट के बिना रेंडर हो पाता है.
एम्बेड की गई चीज़ें
अक्सर इस्तेमाल किए जाने वाले कुछ एम्बेड का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) तय होता है. उदाहरण के लिए, YouTube वीडियो. प्लेयर के लोड होने के दौरान, हम YouTube से थंबनेल लेते हैं और वीडियो लोड होने के दौरान उसका इस्तेमाल प्लेसहोल्डर की तरह करते हैं.
वीडियो पर पड़ने वाले असर को मापना
हमने लेख की शुरुआत में बताए गए टूल का इस्तेमाल करके, सुविधा के स्तर पर असर को आसानी से मेज़र किया. हालांकि, हमें टेंप्लेट और साइट, दोनों लेवल पर सीएलएस को मेज़र करना था. एआई की मदद से, हमने SpeedCurve का इस्तेमाल किया. इससे प्री-प्रोडक्शन और प्रोडक्शन, दोनों में हुए बदलावों की पुष्टि की गई.
कोड के प्रोडक्शन में पहुंचने के बाद, हम अपने आरयूएम डेटा (mPulse से मिला) के नतीजों की पुष्टि कर सकते हैं.
आरयूएम डेटा की जांच करने से हमें इस बात का पूरा भरोसा मिलता है कि हम जो बदलाव कर रहे हैं उनका हमारे पाठकों पर अच्छा असर पड़ रहा है.
हमने जो आखिरी आंकड़े देखे हैं वे Google के इकट्ठा किए गए आरयूएम डेटा से जुड़े हैं. यह खास तौर पर अब ज़रूरी है, क्योंकि जल्द ही पेज की रैंकिंग पर इनका असर होगा. शुरुआत में हमने Chrome UX रिपोर्ट का इस्तेमाल, CrUX डैशबोर्ड से मिले हर महीने के ऑरिजिन लेवल के डेटा के लिए किया. साथ ही, पुराने p75 डेटा को पाने के लिए, BigQuery की क्वेरी करके भी ऐसा किया. इस तरह हम आसानी से यह देख पाए कि CrUX से मेज़र किए गए सभी ट्रैफ़िक के लिए, हमारे 75वें पर्सेंटाइल सीएलएस में 0.25 से 0.1 से 250% की बढ़ोतरी हुई और हमारा पासिंग बकेट 57% से 72%तक बढ़ गया.
इसके अलावा, हम Chrome UX Report API का इस्तेमाल भी कर सकते थे. साथ ही, टेंप्लेट में बंटे हुए कुछ इंटरनल डैशबोर्ड भी बना सकते थे.
सीएलएस रिग्रेशन से बचना
परफ़ॉर्मेंस को बेहतर करने का एक अहम पहलू, रिग्रेशन को रोकना है. हमने अपनी मुख्य मेट्रिक के लिए कुछ बुनियादी परफ़ॉर्मेंस बजट सेट अप किए हैं और उनमें सीएलएस को शामिल किया है.
अगर जांच, बजट से ज़्यादा हो जाती है, तो Slack चैनल पर मैसेज भेजा जाएगा, ताकि हम इस समस्या की जांच कर सकें. हमने साप्ताहिक रिपोर्ट भी सेट की हैं, ताकि टेम्प्लेट का बजट में बने रहने पर भी हमें ऐसे किसी भी बदलाव के बारे में जानकारी रहे जिसका नकारात्मक प्रभाव पड़ा हो.
हम अपने बजट को बढ़ाने की योजना बना रहे हैं, ताकि RUM डेटा के साथ-साथ सिंथेटिक डेटा का भी इस्तेमाल किया जा सके. इसके लिए, mPulse का इस्तेमाल किया जाएगा, ताकि स्टैटिक सूचना और गड़बड़ी की पहचान, दोनों को सेट किया जा सके. इससे हमें किसी भी सामान्य बदलाव के बारे में पता चल जाएगा.
यह ज़रूरी है कि हम सीएलएस को ध्यान में रखते हुए, नई सुविधाओं को आज़माएं. मैंने कई ऐसे बदलावों के बारे में बताया है जिन्हें पाठकों के लिए रिलीज़ किए जाने के बाद हमें ठीक करना पड़ा. आने वाले समय में किसी भी नई सुविधा के समाधान के डिज़ाइन में, लेआउट की स्थिरता पर ध्यान दिया जाएगा, ताकि हम शुरुआत से अनचाहे लेआउट शिफ़्ट से बच सकें.
नतीजा
हमने अब तक जो सुधार किए हैं उन्हें लागू करना काफ़ी आसान है और हमारा काफ़ी असर भी पड़ा है. मैंने इस लेख में जिन बदलावों के बारे में बताया है उन्हें डिलीवर करने में ज़्यादा समय नहीं लगा. इन्हें आम तौर पर इस्तेमाल किए जाने वाले सभी टेंप्लेट पर लागू किया गया. इसका मतलब है कि हमारे पाठकों पर काफ़ी सकारात्मक असर पड़ा.
साइट के अभी भी कुछ क्षेत्रों में सुधार की ज़रूरत है. हम ऐसे तरीके खोज रहे हैं जिनसे हम अपने क्लाइंट-साइड लॉजिक सर्वर-साइड को ज़्यादा कारगर बना सकें. इससे सीएलएस को और बेहतर बनाया जा सकेगा. हम अपनी मेट्रिक को ट्रैक करते रहेंगे और उन पर नज़र रखेंगे, ताकि उन्हें लगातार बेहतर बनाया जा सके और अपने पाठकों को सबसे अच्छा उपयोगकर्ता अनुभव दिया जा सके.