कुछ ही महीनों में, यूनाइटेड किंगडम की एक प्रमुख समाचार वेबसाइट ने अपने 75वें पर्सेंटाइल सीएलएस को 0.25 से 0.1 पर 250% तक बेहतर कर लिया.
विज़ुअल स्टैबिलिटी से जुड़ी चुनौती
लेआउट में होने वाले बदलाव, काफ़ी परेशानी पैदा कर सकते हैं. 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 के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट का इस्तेमाल किया. इसमें, CrUX डैशबोर्ड के ज़रिए हर महीने के ऑरिजिन लेवल का डेटा और 75% उपयोगकर्ताओं के पुराने डेटा को वापस पाने के लिए, BigQuery से क्वेरी करने का इस्तेमाल किया गया. इस तरह, हम आसानी से यह देख पाए कि CrUX से मेज़र किए गए सभी ट्रैफ़िक के लिए, हमारा 75वां प्रतिशत सीएलएस, 0.25 से 0.1 पर पहुंच गया. साथ ही, पास होने वाली बकेट 57% से बढ़कर 72% हो गई.
इसके अलावा, हमने Chrome UX रिपोर्ट एपीआई का इस्तेमाल करके, टेंप्लेट में बांटकर कुछ इंटरनल डैशबोर्ड बनाए.
सीएलएस में गिरावट से बचना
परफ़ॉर्मेंस को बेहतर बनाने के लिए, रेग्रेसन से बचना ज़रूरी है. हमने अपनी मुख्य मेट्रिक के लिए कुछ बुनियादी परफ़ॉर्मेंस बजट सेट अप किए हैं और उनमें सीएलएस को शामिल किया है.
अगर टेस्ट में तय बजट से ज़्यादा खर्च होता है, तो यह Slack चैनल पर एक मैसेज भेजेगा, ताकि हम इसकी वजह की जांच कर सकें. हमने हर हफ़्ते की रिपोर्ट भी सेट अप की हैं, ताकि टेंप्लेट बजट में बने रहें, फिर भी हम उन बदलावों के बारे में जान सकें जिनका बुरा असर पड़ा है.
हम अपने बजट को बढ़ाने की भी योजना बना रहे हैं, ताकि हम RUM डेटा के साथ-साथ सिंथेटिक डेटा का भी इस्तेमाल कर सकें. इसके लिए, हम mPulse का इस्तेमाल करके स्टैटिक सूचनाएं और संभावित गड़बड़ी का पता लगाने की सुविधा सेट करेंगे. इससे, हमें सामान्य से अलग होने वाले किसी भी बदलाव के बारे में पता चलेगा.
हमारे लिए नई सुविधाओं को सीएलएस को ध्यान में रखकर बनाना ज़रूरी है. मैंने जिन बदलावों के बारे में बताया है उनमें से कई ऐसे हैं जिन्हें पाठकों के लिए रिलीज़ करने के बाद, हमें ठीक करना पड़ा. आने वाले समय में, किसी भी नई सुविधा के समाधान के डिज़ाइन में, लेआउट के स्थिर होने का ध्यान रखा जाएगा. इससे, हम शुरुआत से ही लेआउट में होने वाले किसी भी अनचाहे बदलाव से बच पाएंगे.
नतीजा
अब तक हमने जो सुधार किए हैं उन्हें लागू करना काफ़ी आसान था. साथ ही, इनसे काफ़ी फ़ायदा हुआ है. इस लेख में बताए गए कई बदलावों को लागू करने में ज़्यादा समय नहीं लगा. साथ ही, इन्हें सबसे ज़्यादा इस्तेमाल किए जाने वाले सभी टेंप्लेट पर लागू किया गया. इसका मतलब है कि इन बदलावों का हमारे पाठकों पर काफ़ी अच्छा असर पड़ा है.
साइट के कुछ हिस्सों में अब भी सुधार की ज़रूरत है. हम ऐसे तरीकों पर काम कर रहे हैं जिनसे क्लाइंट-साइड लॉजिक को सर्वर-साइड पर ज़्यादा से ज़्यादा इस्तेमाल किया जा सके. इससे सीएलएस को और बेहतर बनाया जा सकेगा. हम अपनी मेट्रिक को ट्रैक और मॉनिटर करते रहेंगे, ताकि हम उन्हें लगातार बेहतर बना सकें और अपने पाठकों को बेहतरीन उपयोगकर्ता अनुभव दे सकें.