LCP, INP और CLS का क्या अर्थ है?

ये तीनों Core Web Vitals हैं, जिनका उपयोग Google किसी पेज के यूज़र अनुभव को परिभाषित करने के लिए करता है। Largest Contentful Paint (LCP) लोडिंग को मापता है: मुख्य कंटेंट दिखने में कितना समय लगता है। Interaction to Next Paint (INP) प्रतिक्रियाशीलता को मापता है: क्लिक करने, टैप करने या टाइप करने पर पेज कितनी तेज़ी से प्रतिक्रिया देता है। Cumulative Layout Shift (CLS) विज़ुअल स्थिरता को मापता है: लेआउट कितना इधर-उधर खिसकता है। अच्छे स्कोर का मतलब है LCP 2.5 सेकंड के भीतर, INP 200 मिलीसेकंड के भीतर और CLS 0.1 या उससे कम।

तीनों मेट्रिक्स एक नज़र में

ये सीमाएँ Google की Core Web Vitals रिपोर्ट सहायता में दी गई हैं। कोई पेज तब पास माना जाता है जब तीनों मेट्रिक्स विज़िट के 75वें पर्सेंटाइल पर अच्छे हों, और यह मोबाइल व डेस्कटॉप के लिए अलग-अलग मापा जाता है।

LCP: Largest Contentful Paint

LCP वह समय है जो पेज लोड होना शुरू होने से लेकर दिखाई देने वाले क्षेत्र की सबसे बड़ी इमेज, वीडियो या टेक्स्ट ब्लॉक के रेंडर होने तक लगता है। इसमें <img> एलिमेंट, SVG के भीतर की इमेज, वीडियो का पोस्टर या पहला फ़्रेम, CSS बैकग्राउंड इमेज और ब्लॉक-लेवल टेक्स्ट शामिल हैं। विज़िटर के पेज के साथ इंटरैक्ट करते ही ब्राउज़र नए उम्मीदवार खोजना बंद कर देता है। धीमा LCP आमतौर पर धीमे सर्वर रिस्पॉन्स, बड़ी या देर से खोजी गई हीरो इमेज, या रेंडरिंग को रोकने वाले CSS और स्क्रिप्ट के कारण होता है।

INP: Interaction to Next Paint

INP किसी विज़िट के दौरान क्लिक, टैप और कीप्रेस पर नज़र रखता है और मापता है कि ब्राउज़र को अगला फ़्रेम पेंट करने में हर बार कितना समय लगा। होवर करना, स्क्रॉल करना और ज़ूम करना इसमें नहीं गिने जाते। रिपोर्ट किया गया मान सबसे धीमा इंटरैक्शन होता है, और बहुत अधिक इंटरैक्शन वाले पेजों में अपवाद-स्वरूप मान छोड़ दिए जाते हैं। INP ने मार्च 2024 में First Input Delay (FID) की जगह Core Web Vital का स्थान लिया; FID केवल पहले इंटरैक्शन को देखता था, जबकि INP पूरी विज़िट को कवर करता है। खराब INP आमतौर पर लंबे JavaScript टास्क के कारण आता है, जो मुख्य थ्रेड को व्यस्त रखते हैं।

CLS: Cumulative Layout Shift

CLS अप्रत्याशित लेआउट शिफ़्ट को जोड़ता है, जैसे ऊपर कोई इमेज या विज्ञापन लोड होने पर टेक्स्ट का नीचे खिसक जाना, और विज़िट के दौरान इनके सबसे बड़े समूह की रिपोर्ट करता है। हर शिफ़्ट को इस आधार पर स्कोर मिलता है कि स्क्रीन का कितना हिस्सा और कितनी दूर तक खिसका। क्लिक, टैप या कीप्रेस के 500 मिलीसेकंड के भीतर होने वाली शिफ़्ट को बाहर रखा जाता है, क्योंकि उस समय विज़िटर पेज के बदलने की अपेक्षा करता है।

ये आँकड़े कहाँ से आते हैं?

Search Console की Core Web Vitals रिपोर्ट Chrome UX Report के फ़ील्ड डेटा का उपयोग करती है: पिछले 28 दिनों की वास्तविक Chrome विज़िट, जिन्हें समान पेजों के समूहों में बाँटा जाता है, और हर समूह को उसकी सबसे खराब मेट्रिक के आधार पर रेट किया जाता है। Lighthouse जैसे लैब टूल पेज को बिना किसी वास्तविक विज़िटर के लोड करते हैं, इसलिए वे INP नहीं माप सकते और उसके विकल्प के रूप में Total Blocking Time का उपयोग करते हैं, जैसा कि web.dev का Web Vitals का अवलोकन बताता है। लैब स्कोर को डीबग करने का साधन मानें, और फ़ील्ड डेटा को अंतिम निर्णय।

क्या Core Web Vitals रैंकिंग को प्रभावित करते हैं?

Google दृढ़ता से अनुशंसा करता है कि Search में सफलता के लिए अच्छे Core Web Vitals हासिल किए जाएँ, और कहता है कि पेज अनुभव उन बातों से मेल खाता है जिन्हें उसके मुख्य रैंकिंग सिस्टम पुरस्कृत करना चाहते हैं। यह कोई शॉर्टकट नहीं है: तेज़ पेज को फिर भी सबसे अच्छा उत्तर होना चाहिए। खराब Core Web Vitals स्कोर को कैसे ठीक करें? में बताया गया है कि हर मेट्रिक के लिए क्या बदलना चाहिए।

AutoPSEO कैसे मदद करता है

AutoPSEO की Core Web Vitals रिपोर्ट आपकी पूरी साइट या किसी एक URL के लिए, फ़ोन, डेस्कटॉप या टैबलेट के अनुसार, Chrome UX Report का इतिहास पढ़ती है और लगभग छह महीनों के साप्ताहिक डेटा पर 75वें पर्सेंटाइल पर LCP, INP और CLS (साथ ही first contentful paint और time to first byte) का चार्ट बनाती है, ताकि आप देख सकें कि कोई मेट्रिक कब गिरना शुरू हुई।