Cumulative Layout Shift (CLS)

Milica Mihajlija

Philip Walton

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

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

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

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

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

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

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

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

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

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

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

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

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

लेआउट शिफ़्ट की जानकारी

लेआउट शिफ़्ट, Layout Instability API से तय किए जाते हैं. यह किसी भी समय, 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 है.

उदाहरण

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

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

"क्लिक मी!" बटन पहले डीओएम में नहीं था. इसलिए, इसकी स्टार्ट पोज़िशन भी नहीं बदलती.

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

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

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

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

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

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

फिर से, लाल, बिंदुदार आयत इन तीन असुरक्षित तत्वों' के संयोजन को दिखाते हैं क्षेत्रों के पहले और बाद में, जो इस मामले में व्यूपोर्ट के क्षेत्र का करीब 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
• लाइटहाउस
• 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 पब्लिशर टैग से जुड़े दिशा-निर्देश
• #PerfMatters पर ऐनी सलिवन और स्टीव कोबेस ने लेआउट में होने वाले बदलाव को समझना (2020)

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

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

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

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