Cumulative Layout Shift (CLS)

Milica Mihajlija

Philip Walton

अचानक लेआउट में होने वाले बदलाव, उपयोगकर्ता अनुभव को कई तरह से खराब कर सकते हैं. जैसे, टेक्स्ट अचानक मूव होने पर, पढ़ते समय उपयोगकर्ता को अपनी जगह का पता नहीं चलता. इसके अलावा, गलत लिंक या बटन पर क्लिक करने की संभावना भी बढ़ जाती है. कुछ मामलों में, इससे गंभीर नुकसान हो सकता है.

पेज के कॉन्टेंट में अचानक बदलाव होने की समस्या आम तौर पर तब होती है, जब रिसॉर्स एसिंक्रोनस तरीके से लोड होते हैं या मौजूदा कॉन्टेंट से पहले, पेज में डाइनैमिक तौर पर DOM एलिमेंट जोड़े जाते हैं. लेआउट में बदलाव होने की वजह, ऐसे डाइमेंशन वाली इमेज या वीडियो हो सकते हैं जिनके बारे में जानकारी नहीं है. इसके अलावा, ऐसे फ़ॉन्ट भी हो सकते हैं जो अपने शुरुआती फ़ॉलबैक से बड़े या छोटे रेंडर होते हैं. इसके अलावा, तीसरे पक्ष के ऐसे विज्ञापन या विजेट भी हो सकते हैं जो अपने-आप डाइनैमिक तरीके से साइज़ बदलते हैं.

डेवलपमेंट के दौरान साइट के काम करने के तरीके और उपयोगकर्ताओं को मिलने वाले अनुभव में अंतर होने पर, यह समस्या और भी गंभीर हो जाती है. उदाहरण के लिए:

• लोगों के हिसाब से बनाया गया या तीसरे पक्ष का कॉन्टेंट, डेवलपमेंट और प्रोडक्शन के दौरान अक्सर अलग-अलग तरीके से काम करता है.
• टेस्ट इमेज अक्सर डेवलपर के ब्राउज़र कैश मेमोरी में पहले से मौजूद होती हैं. हालांकि, असली उपयोगकर्ता के लिए इन्हें लोड होने में ज़्यादा समय लगता है.
• स्थानीय तौर पर चलने वाले एपीआई कॉल अक्सर इतने तेज़ होते हैं कि डेवलपमेंट में होने वाली छोटी-मोटी देरी, प्रोडक्शन में काफ़ी बड़ी हो सकती है.

कुल लेआउट शिफ़्ट (सीएलएस) मेट्रिक की मदद से, इस समस्या को हल किया जा सकता है. यह मेट्रिक यह मेज़र करती है कि असल उपयोगकर्ताओं के लिए यह समस्या कितनी बार आ रही है.

सीएलएस क्या है?

सीएलएस, किसी पेज के पूरे लाइफ़साइकल के दौरान, अचानक होने वाले हर अनचाहे लेआउट शिफ़्ट के लिए, लगातार होने वाले लेआउट शिफ़्ट स्कोर का आकलन करती है.

जब भी कोई दिखने वाला एलिमेंट, रेंडर किए गए एक फ़्रेम से दूसरे फ़्रेम में अपनी पोज़िशन बदलता है, तब लेआउट शिफ़्ट होता है. (अलग-अलग लेआउट शिफ़्ट के स्कोर का हिसाब लगाने के तरीके के बारे में जानकारी, इस गाइड में आगे दी गई है.)

सेशन विंडो, लेआउट शिफ़्ट का एक बर्स्ट होता है. यह तब होता है, जब एक या उससे ज़्यादा लेआउट शिफ़्ट एक-दूसरे के बाद तेज़ी से होती हैं. साथ ही, हर शिफ़्ट के बीच का समय एक सेकंड से कम और विंडो की कुल अवधि ज़्यादा से ज़्यादा पांच सेकंड होती है.

सबसे ज़्यादा बर्स्ट, उस सेशन विंडो में होता है जिसमें सभी लेआउट शिफ़्ट का कुल स्कोर सबसे ज़्यादा होता है.

अच्छा सीएलएस स्कोर क्या होता है?

उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, यह ज़रूरी है कि साइटों का सीएलएस स्कोर 0.1 या उससे कम हो. यह पक्का करने के लिए कि आपके ज़्यादातर उपयोगकर्ताओं के लिए यह टारगेट पूरा हो रहा है, पेज लोड के 75वें प्रतिशत को मेज़र करना एक अच्छा थ्रेशोल्ड है. इसे मोबाइल और डेस्कटॉप डिवाइसों के हिसाब से सेगमेंट किया जाता है.

इस सुझाव के पीछे की रिसर्च और तरीके के बारे में ज़्यादा जानने के लिए, Core Web Vitals मेट्रिक के थ्रेशोल्ड तय करना लेख पढ़ें.

लेआउट शिफ़्ट के बारे में ज़्यादा जानकारी

लेआउट में होने वाले बदलावों की जानकारी, लेआउट में होने वाले बदलावों से जुड़ा एपीआई देता है. यह एपीआई, दो फ़्रेम के बीच में व्यूपोर्ट में दिखने वाले किसी एलिमेंट की शुरुआती पोज़िशन (उदाहरण के लिए, डिफ़ॉल्ट लिखने के मोड में उसका ऊपरी और बाईं ओर वाला पोज़िशन) में होने वाले बदलावों के बारे में layout-shift एंट्री की रिपोर्ट करता है. ऐसे एलिमेंट को अस्थिर एलिमेंट माना जाता है.

ध्यान दें कि लेआउट शिफ़्ट सिर्फ़ तब होते हैं, जब मौजूदा एलिमेंट अपनी शुरुआती पोज़िशन बदलते हैं. अगर डीओएम में कोई नया एलिमेंट जोड़ा जाता है या किसी मौजूदा एलिमेंट का साइज़ बदल जाता है, तो इसे लेआउट शिफ़्ट नहीं माना जाता. ऐसा तब तक होता है, जब तक कि बदलाव की वजह से दिखने वाले अन्य एलिमेंट की शुरुआती पोज़िशन में बदलाव न हो.

लेआउट शिफ़्ट स्कोर

लेआउट शिफ़्ट स्कोर का हिसाब लगाने के लिए, ब्राउज़र दो रेंडर किए गए फ़्रेम के बीच व्यूपोर्ट के साइज़ और व्यूपोर्ट में अस्थिर एलिमेंट की गति को देखता है. लेआउट शिफ़्ट स्कोर, उस मूवमेंट के दो मेज़र का प्रॉडक्ट होता है: इफ़ेक्ट फ़्रैक्शन और डिस्टेंस फ़्रैक्शन. इन दोनों के बारे में नीचे बताया गया है.

layout shift score = impact fraction * distance fraction

इंपैक्ट फ़्रैक्शन

इफ़ेक्ट फ़्रैक्शन से पता चलता है कि अस्थिर एलिमेंट, दो फ़्रेम के बीच व्यूपोर्ट एरिया पर कैसे असर डालते हैं.

किसी फ़्रेम के लिए असर का फ़्रैक्शन, उस फ़्रेम और पिछले फ़्रेम के सभी अस्थिर एलिमेंट के दिखने वाले हिस्सों का कॉम्बिनेशन होता है. यह वैपर्ट पैनल के कुल हिस्से के फ़्रैक्शन के तौर पर होता है.

पिछली इमेज में, एक ऐसा एलिमेंट है जो एक फ़्रेम में व्यूपोर्ट का आधा हिस्सा लेता है. इसके बाद, अगले फ़्रेम में एलिमेंट, व्यूपोर्ट की ऊंचाई के 25% तक नीचे चला जाता है. लाल रंग के बिंदुओं वाला रेक्टैंगल, दोनों फ़्रेम में एलिमेंट के दिखने वाले हिस्से को दिखाता है. इस मामले में, यह कुल व्यूपोर्ट का 75% है. इसलिए, इसका इफ़ेक्ट फ़्रैक्शन 0.75 है.

दूरी का फ़्रैक्शन

लेआउट शिफ़्ट स्कोर के समीकरण का दूसरा हिस्सा, उस दूरी को मेज़र करता है जो अस्थिर एलिमेंट, व्यूपोर्ट के हिसाब से आगे-पीछे हुए हैं. डिस्टेंस फ़्रैक्शन, फ़्रेम में किसी भी अस्थिर एलिमेंट की सबसे बड़ी हॉरिज़ॉन्टल या वर्टिकल दूरी होती है. इसे व्यूपोर्ट के सबसे बड़े डाइमेंशन (चौड़ाई या ऊंचाई, जो भी ज़्यादा हो) से भाग दिया जाता है.

पिछले उदाहरण में, व्यूपोर्ट का सबसे बड़ा डाइमेंशन ऊंचाई है और अस्थिर एलिमेंट, व्यूपोर्ट की ऊंचाई का 25% तक चला गया है. इससे डिस्टेंस फ़्रैक्शन 0.25 हो जाता है.

इसलिए, इस उदाहरण में इफ़ेक्ट फ़्रैक्शन 0.75 और डिस्टेंस फ़्रैक्शन 0.25 है. इसलिए, लेआउट शिफ़्ट स्कोर 0.75 * 0.25 = 0.1875 है.

उदाहरण

अगले उदाहरण में बताया गया है कि किसी मौजूदा एलिमेंट में कॉन्टेंट जोड़ने से, लेआउट शिफ़्ट स्कोर पर क्या असर पड़ता है:

इस उदाहरण में, स्लेटी बॉक्स का साइज़ बदलता है, लेकिन उसकी शुरुआती पोज़िशन नहीं बदलती. इसलिए, यह अस्थिर एलिमेंट नहीं है.

"मुझ पर क्लिक करें!" बटन पहले DOM में नहीं था, इसलिए इसकी शुरुआती स्थिति भी नहीं बदलती.

हालांकि, हरे बॉक्स की शुरुआती स्थिति बदल जाती है. हालांकि, इसे व्यूपोर्ट से कुछ हद तक बाहर ले जाया गया है. इसलिए, इफ़ेक्ट फ़्रैक्शन का हिसाब लगाते समय, न दिखने वाले हिस्से को शामिल नहीं किया जाता. दोनों फ़्रेम में हरे बॉक्स के दिखने वाले हिस्सों (लाल बिंदु वाले रेक्टैंगल से दिखाया गया है) का कुल क्षेत्र, पहले फ़्रेम में हरे बॉक्स के क्षेत्र के बराबर है. यह क्षेत्र, व्यूपोर्ट का 50% है. इफ़ेक्ट फ़्रैक्शन 0.5 है.

दूरी का फ़्रैक्शन, बैंगनी रंग के ऐरो से दिखाया गया है. हरा बॉक्स, व्यूपोर्ट के करीब 14% नीचे चला गया है. इसलिए, डिस्टेंस फ़्रैक्शन 0.14 है.

लेआउट शिफ़्ट स्कोर 0.5 x 0.14 = 0.07 है.

इस उदाहरण में दिखाया गया है कि एक से ज़्यादा अस्थिर एलिमेंट, पेज के लेआउट शिफ़्ट स्कोर पर कैसे असर डालते हैं:

ऊपर दी गई इमेज के पहले फ़्रेम में, जानवरों के लिए किए गए एपीआई अनुरोध के चार नतीजे दिख रहे हैं. इन्हें वर्णमाला के क्रम में क्रम से लगाया गया है. दूसरे फ़्रेम में, क्रम से लगाई गई सूची में ज़्यादा नतीजे जोड़े गए हैं.

सूची में मौजूद पहला आइटम ("बिल्ली") फ़्रेम के बीच अपनी शुरुआती स्थिति में नहीं बदलता है, इसलिए यह स्थिर है. इसी तरह, सूची में जोड़े गए नए आइटम पहले DOM में मौजूद नहीं थे. इसलिए, उनकी शुरुआती पोज़िशन भी नहीं बदलती. हालांकि, "कुत्ता", "घोड़ा", और "ज़ेबरा" लेबल वाले आइटम, अपनी शुरुआती जगहों से हट जाते हैं. इससे, उन्हें अस्थिर एलिमेंट माना जाता है.

फिर से, लाल रंग के बिंदु वाले रेक्टैंगल, इन तीन अस्थिर एलिमेंट के पहले और बाद के एरिया को दिखाते हैं. इस मामले में, यह व्यूपोर्ट के एरिया का करीब 60% है (0.60 का इफ़ेक्ट फ़्रैक्शन).

ऐरो से पता चलता है कि अस्थिर एलिमेंट अपनी शुरुआती जगहों से कितनी दूरी तक चले गए हैं. नीले ऐरो से दिखाए गए "ज़ेबरा" एलिमेंट की स्थिति में सबसे ज़्यादा बदलाव हुआ है. यह व्यूपोर्ट की ऊंचाई के करीब 30% तक नीचे चला गया है. इस उदाहरण में, दूरी का फ़्रैक्शन 0.3 है.

लेआउट शिफ़्ट स्कोर 0.60 x 0.3 = 0.18 है.

लेआउट में होने वाले अनुमानित और अनचाहे बदलाव

लेआउट में होने वाले सभी बदलाव खराब नहीं होते. असल में, कई डाइनैमिक वेब ऐप्लिकेशन, पेज पर एलिमेंट की शुरुआती पोज़िशन को बार-बार बदलते रहते हैं. लेआउट शिफ़्ट तब ही खराब होता है, जब उपयोगकर्ता को इसकी उम्मीद न हो.

उपयोगकर्ता की ओर से लेआउट में होने वाले बदलाव

आम तौर पर, उपयोगकर्ता के इंटरैक्शन (जैसे, किसी लिंक पर क्लिक या टैप करना, किसी बटन को दबाना या खोज बॉक्स में टाइप करना) के जवाब में लेआउट में होने वाले बदलाव ठीक होते हैं. हालांकि, यह ज़रूरी है कि बदलाव, इंटरैक्शन के तुरंत बाद हो, ताकि उपयोगकर्ता को यह पता चल सके कि बदलाव किस वजह से हुआ है.

उदाहरण के लिए, अगर उपयोगकर्ता के इंटरैक्शन से कोई ऐसा नेटवर्क अनुरोध ट्रिगर होता है जिसे पूरा होने में कुछ समय लग सकता है, तो बेहतर होगा कि आप तुरंत कुछ जगह खाली कर दें और लोडिंग इंडिकेटर दिखाएं. इससे अनुरोध पूरा होने पर, लेआउट में अचानक होने वाले बदलाव से बचा जा सकता है. अगर उपयोगकर्ता को यह पता नहीं चलता कि कोई कॉन्टेंट लोड हो रहा है या उसे यह नहीं पता कि संसाधन कब तैयार होगा, तो हो सकता है कि वह इंतज़ार करते समय किसी दूसरे कॉन्टेंट पर क्लिक कर दे. ऐसा कॉन्टेंट जो शायद उसके लिए उपलब्ध न हो.

उपयोगकर्ता के इनपुट के 500 मिलीसेकंड के अंदर होने वाले लेआउट शिफ़्ट पर hadRecentInput फ़्लैग सेट होगा, ताकि उन्हें कैलकुलेशन से बाहर रखा जा सके.

ऐनिमेशन और ट्रांज़िशन

सही तरीके से इस्तेमाल किए जाने पर, एनिमेशन और ट्रांज़िशन, उपयोगकर्ता को चौंकाए बिना पेज पर कॉन्टेंट को अपडेट करने का एक बेहतरीन तरीका है. पेज पर अचानक और अनचाहे तरीके से दिखने वाला कॉन्टेंट, उपयोगकर्ता अनुभव को खराब करता है. हालांकि, धीरे-धीरे और स्वाभाविक तरीके से एक पोज़िशन से दूसरी पोज़िशन पर जाने वाले कॉन्टेंट से, उपयोगकर्ता को यह समझने में मदद मिलती है कि क्या हो रहा है. साथ ही, स्टेटस में बदलाव होने पर, उन्हें दिशा-निर्देश भी मिलते हैं.

ब्राउज़र की prefers-reduced-motion सेटिंग का ध्यान रखें, क्योंकि साइट पर आने वाले कुछ लोगों को ऐनिमेशन से बुरा असर पड़ सकता है या उनकी ध्यान देने की क्षमता पर असर पड़ सकता है.

सीएसएस transform प्रॉपर्टी की मदद से, लेआउट में बदलाव किए बिना एलिमेंट को ऐनिमेट किया जा सकता है:

• height और width प्रॉपर्टी बदलने के बजाय, transform: scale() का इस्तेमाल करें.
• एलिमेंट को एक जगह से दूसरी जगह ले जाने के लिए, top, right, bottom या left प्रॉपर्टी में बदलाव करने से बचें. इसके बजाय, transform: translate() का इस्तेमाल करें.

सीएलएस को मेज़र करने का तरीका

सीएलएस को लैब में या फ़ील्ड में मेज़र किया जा सकता है. यह इन टूल में उपलब्ध है:

फ़ील्ड टूल

• Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट
• PageSpeed Insights
• Search Console (वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी वाली रिपोर्ट)
• web-vitals JavaScript लाइब्रेरी

लैब टूल

• Chrome DevTools
• Lighthouse
• PageSpeed Insights
• WebPageTest

JavaScript में लेआउट में हुए बदलावों को मेज़र करना

JavaScript में लेआउट में होने वाले बदलावों को मेज़र करने के लिए, Layout Instability API का इस्तेमाल किया जाता है.

यहां दिए गए उदाहरण में, कंसोल में layout-shift एंट्री को लॉग करने के लिए PerformanceObserver बनाने का तरीका बताया गया है:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

JavaScript में सीएलएस मेज़र करना

JavaScript में सीएलएस मेज़र करने के लिए, आपको इन अनचाही layout-shift एंट्री को सेशन में ग्रुप करना होगा और सेशन की सबसे बड़ी वैल्यू का हिसाब लगाना होगा. web vitals JavaScript लाइब्रेरी के सोर्स कोड को देखा जा सकता है. इसमें सीएलएस का हिसाब लगाने के तरीके के बारे में रेफ़रंस लागू करने की जानकारी होती है.

ज़्यादातर मामलों में, पेज के अनलोड होने के समय की मौजूदा सीएलएस वैल्यू, उस पेज के लिए सीएलएस की फ़ाइनल वैल्यू होती है. हालांकि, कुछ अहम अपवाद भी हैं, जिनके बारे में अगले सेक्शन में बताया गया है. web vitals JavaScript लाइब्रेरी, वेब एपीआई की सीमाओं के मुताबिक इनका ज़्यादा से ज़्यादा ध्यान रखती है.

मेट्रिक और एपीआई के बीच अंतर

• अगर कोई पेज बैकग्राउंड में लोड होता है या ब्राउज़र किसी कॉन्टेंट को दिखाने से पहले उसे बैकग्राउंड में डाल देता है, तो उसे कोई सीएलएस वैल्यू नहीं दिखानी चाहिए.
• अगर किसी पेज को बैक/फ़ॉरवर्ड कैश मेमोरी से वापस लाया जाता है, तो उसकी सीएलएस वैल्यू को शून्य पर रीसेट किया जाना चाहिए. ऐसा इसलिए, क्योंकि उपयोगकर्ताओं को यह अलग पेज विज़िट के तौर पर दिखता है.
• एपीआई, iframe में होने वाले बदलावों के लिए layout-shift एंट्री की रिपोर्ट नहीं करता. हालांकि, मेट्रिक ऐसा करती है, क्योंकि ये पेज के उपयोगकर्ता अनुभव का हिस्सा हैं. यह CrUX और RUM के बीच अंतर के तौर पर दिख सकता है. सीएलएस को सही तरीके से मेज़र करने के लिए, आपको इन बातों का ध्यान रखना चाहिए. सब-फ़्रेम, एग्रीगेशन के लिए पैरंट फ़्रेम को अपनी layout-shift एंट्री की रिपोर्ट करने के लिए, एपीआई का इस्तेमाल कर सकते हैं.

इन अपवादों के अलावा, सीएलएस को मेज़र करना थोड़ा मुश्किल होता है. इसकी वजह यह है कि यह किसी पेज के पूरे लाइफ़स्पैन को मेज़र करता है:

• उपयोगकर्ता किसी टैब को काफ़ी लंबे समय तक खुला रख सकते हैं. जैसे, दिनों, हफ़्तों, महीनों तक. ऐसा हो सकता है कि कोई उपयोगकर्ता कभी भी टैब बंद न करे.
• मोबाइल ऑपरेटिंग सिस्टम पर, ब्राउज़र आम तौर पर बैकग्राउंड टैब के लिए, पेज अनलोड होने के कॉलबैक नहीं चलाते. इससे "फ़ाइनल" वैल्यू की रिपोर्ट करना मुश्किल हो जाता है.

ऐसे मामलों को हैंडल करने के लिए, जब भी कोई पेज बैकग्राउंड में हो, तब सीएलएस की रिपोर्ट की जानी चाहिए. साथ ही, जब भी पेज अनलोड हो, तब भी सीएलएस की रिपोर्ट की जानी चाहिए. visibilitychange इवेंट, इन दोनों स्थितियों को कवर करता है. इसके बाद, इस डेटा को पाने वाले Analytics सिस्टम को बैकएंड पर सीएलएस की फ़ाइनल वैल्यू का हिसाब लगाना होगा.

डेवलपर, सीएलएस को मेज़र करने के लिए, web-vitals JavaScript लाइब्रेरी का इस्तेमाल कर सकते हैं. इसमें iframe केस को छोड़कर, ऊपर बताई गई सभी चीज़ों को शामिल किया जाता है:

import {onCLS} from 'web-vitals';

// Measure and log CLS in all situations
// where it needs to be reported.
onCLS(console.log);

सीएलएस को बेहतर बनाने का तरीका

फ़ील्ड में लेआउट शिफ़्ट की पहचान करने और उन्हें ऑप्टिमाइज़ करने के लिए लैब डेटा का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, सीएलएस को ऑप्टिमाइज़ करने से जुड़ी हमारी गाइड देखें.

अन्य संसाधन

• लेआउट शिफ़्ट को कम करने के बारे में Google Publisher Tag का दिशा-निर्देश
• #PerfMatters (2020) में ऐनी सलिवन और स्टीव कोबस की कुल लेआउट शिफ़्ट को समझना

बदलावों का लॉग

कभी-कभी, मेट्रिक को मेज़र करने के लिए इस्तेमाल किए जाने वाले एपीआई में गड़बड़ियां मिलती हैं. साथ ही, कभी-कभी मेट्रिक की परिभाषाओं में भी गड़बड़ियां मिलती हैं. इसलिए, कभी-कभी बदलाव करना ज़रूरी होता है. ये बदलाव, आपकी इंटरनल रिपोर्ट और डैशबोर्ड में सुधार या गिरावट के तौर पर दिख सकते हैं.

इसे मैनेज करने में आपकी मदद करने के लिए, इन मेट्रिक को लागू करने या उनकी परिभाषा में किए गए सभी बदलाव, इस बदलावों की सूची में दिखाए जाएंगे.

अगर आपको इन मेट्रिक के बारे में कोई सुझाव, शिकायत या राय देनी है, तो web-vitals-feedback Google ग्रुप में जाकर ऐसा किया जा सकता है.