इस पेज का अनुवाद Cloud Translation API से किया गया है.

कुल लेआउट शिफ़्ट (सीएलएस)

Milica Mihajlija

Philip Walton

Browser Support

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

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

लेआउट में अचानक हुए बदलाव की वजह से, उपयोगकर्ता को एक बड़े ऑर्डर की पुष्टि करनी पड़ती है जिसे वह रद्द करना चाहता था.

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

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

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

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

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

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

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

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

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

सेशन विंडो का उदाहरण. नीले बार, हर लेआउट शिफ़्ट के स्कोर दिखाते हैं.

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

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

अच्छी सीएलएस वैल्यू 0.1 या उससे कम होती हैं. खराब वैल्यू 0.25 से ज़्यादा होती हैं. इन दोनों के बीच की वैल्यू में सुधार की ज़रूरत होती है — अच्छी सीएलएस वैल्यू 0.1 या उससे कम होती हैं. खराब वैल्यू 0.25 से ज़्यादा होती हैं.

इस सुझाव के पीछे की रिसर्च और तरीके के बारे में ज़्यादा जानने के लिए, 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 फ़्लैग सेट होगा, ताकि उन्हें कैलकुलेशन से बाहर रखा जा सके.

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

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

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

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

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

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

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

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

फ़ील्ड टूल

लैब टूल

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 इवेंट, इन दोनों स्थितियों को कवर करता है. इसके बाद, इस डेटा को पाने वाले आंकड़ों के सिस्टम को बैकएंड पर सीएलएस की फ़ाइनल वैल्यू का हिसाब लगाना होगा.

डेवलपर, सीएलएस को मेज़र करने के लिए 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 ग्रुप में जाकर ऐसा किया जा सकता है.