Core Web Vitals समझें: LCP, INP और CLS गाइड (2026)

Q: क्या Core Web Vitals डेस्कटॉप पर मायने रखते हैं?

हाँ। Google मोबाइल और डेस्कटॉप का अलग अलग मूल्यांकन करता है। मोबाइल पर पास होना आमतौर पर ज़्यादा मुश्किल होता है क्योंकि डिवाइस और नेटवर्क धीमे होते हैं।

Core Web Vitals तीन मेट्रिक्स हैं जिनसे Google किसी पेज के असली अनुभव को मापता है: वह कितनी जल्दी लोड होता है, कितनी जल्दी रिस्पॉन्ड करता है और लोड होते समय कितना स्थिर रहता है। ये उन पेज एक्सपीरियंस संकेतों का हिस्सा हैं जिन पर Google रैंकिंग में विचार करता है, और – इससे भी ज़रूरी – ये दर्शाते हैं कि विज़िटर आपकी साइट के बारे में असल में कैसा महसूस करते हैं।

तीन Core Web Vitals

मेट्रिक	क्या मापता है	अच्छा	सुधार की ज़रूरत	खराब
LCP – Largest Contentful Paint	लोडिंग: मुख्य कंटेंट कब दिखता है	≤ 2.5 s	2.5–4.0 s	> 4.0 s
INP – Interaction to Next Paint	रिस्पॉन्सिवनेस: पेज इनपुट पर कितनी जल्दी प्रतिक्रिया देता है	≤ 200 ms	200–500 ms	> 500 ms
CLS – Cumulative Layout Shift	विज़ुअल स्थिरता: लेआउट कितना उछलता है	≤ 0.1	0.1–0.25	> 0.25

कोई पेज तब पास होता है जब कम से कम 75% असली विज़िट (75वाँ पर्सेंटाइल) तीनों मेट्रिक्स के लिए “अच्छा” सीमा पूरी करती हैं।

मार्च 2024 में INP ने Core Web Vital के रूप में First Input Delay (FID) की जगह ली। INP ज़्यादा सख्त है: यह सिर्फ़ पहले इंटरैक्शन की नहीं, पूरी विज़िट के दौरान के इंटरैक्शन की रिस्पॉन्सिवनेस देखता है।

फ़ील्ड डेटा बनाम लैब डेटा

फ़ील्ड डेटा असली Chrome यूज़र से आता है और Chrome UX Report (CrUX) में 28 दिनों की चलती अवधि में इकट्ठा होता है। Google पेज एक्सपीरियंस के लिए यही इस्तेमाल करता है। आप इसे Search Console की Core Web Vitals रिपोर्ट और PageSpeed Insights में देख सकते हैं।

लैब डेटा एक तय डिवाइस और नेटवर्क पर Lighthouse जैसे सिम्युलेटेड टेस्ट से आता है। यह डीबग करने और बदलाव टेस्ट करने के लिए बढ़िया है, लेकिन Google रैंकिंग के लिए इसे इस्तेमाल नहीं करता – और यह सीधे INP नहीं माप सकता (Total Blocking Time सबसे करीबी लैब विकल्प है)।

Core Web Vitals जाँचक

किसी पेज और पूरी साइट के लिए Chrome UX Report से असली यूज़र के LCP, INP और CLS देखें।

Core Web Vitals जाँचक खोलें

कम ट्रैफ़िक वाले पेजों के पास पर्याप्त फ़ील्ड डेटा नहीं हो सकता; ऐसे में Google मिलते-जुलते पेजों या पूरी साइट (“origin”) का डेटा इस्तेमाल कर सकता है।

Largest Contentful Paint (LCP)

LCP उस समय को दर्शाता है जब viewport की सबसे बड़ी इमेज या टेक्स्ट ब्लॉक रेंडर होना पूरा होता है – आमतौर पर हीरो इमेज, बड़ी हेडिंग या फ़ीचर्ड वीडियो का पोस्टर।

LCP को चार हिस्सों में बाँटा जा सकता है, जो सुधार की दिशा बताते हैं:

Time to First Byte – सर्वर को जवाब देने में कितना समय लगता है
रिसोर्स लोड डिले – ब्राउज़र के LCP रिसोर्स डाउनलोड करना शुरू करने से पहले कितना समय
रिसोर्स लोड टाइम – डाउनलोड में कितना समय लगता है
एलिमेंट रेंडर डिले – डाउनलोड और रेंडरिंग के बीच का समय

LCP कैसे सुधारें

सर्वर तेज़ करें: पेज कैशिंग, CDN, तेज़ होस्टिंग और कम डेटाबेस क्वेरी
LCP इमेज को जल्दी खोजे जाने लायक बनाएँ: HTML में सामान्य <img> इस्तेमाल करें (CSS बैकग्राउंड या JavaScript से डाली गई इमेज नहीं) और fetchpriority="high" जोड़ें
LCP इमेज को कभी लेज़ी-लोड न करें
इमेज ऑप्टिमाइज़ करें: सही डाइमेंशन, WebP या AVIF, अच्छा कम्प्रेशन
रेंडर-ब्लॉकिंग रिसोर्स घटाएँ: ज़रूरी CSS इनलाइन करें, गैर-ज़रूरी JavaScript defer करें
इमेज CDN जैसे ज़रूरी थर्ड-पार्टी origin के लिए preconnect करें

Interaction to Next Paint (INP)

INP किसी यूज़र इंटरैक्शन – क्लिक, टैप या की दबाना – और स्क्रीन पर अगले विज़ुअल अपडेट के बीच की देरी मापता है। यह विज़िट के दौरान के सबसे धीमे इंटरैक्शन में से एक की रिपोर्ट करता है।

खराब INP आमतौर पर main thread पर बहुत ज़्यादा JavaScript चलने से आता है, जिससे ब्राउज़र जल्दी रिस्पॉन्ड नहीं कर पाता।

INP कैसे सुधारें

JavaScript घटाएँ और बाँटें: बिना इस्तेमाल की लाइब्रेरी हटाएँ, code-split करें और फ़ीचर सिर्फ़ ज़रूरत पड़ने पर लोड करें
लंबे टास्क तोड़ें: 50 ms से ज़्यादा के टास्क main thread को ब्लॉक करते हैं; काम के हिस्सों के बीच ब्राउज़र को मौका दें
थर्ड-पार्टी स्क्रिप्ट का ऑडिट करें: टैग मैनेजर, चैट विजेट, A/B टेस्टिंग टूल और विज्ञापन स्क्रिप्ट अक्सर ज़िम्मेदार होते हैं
DOM को हल्का रखें: बहुत बड़े पेज हर अपडेट को धीमा करते हैं
इंटरैक्शन पर तुरंत विज़ुअल फ़ीडबैक दें, फिर भारी काम बाद में करें

Cumulative Layout Shift (CLS)

CLS अप्रत्याशित लेआउट हलचल मापता है – वह झुंझलाने वाला अनुभव जब आप टैप करने ही वाले हों और बटन उछलकर दूर चला जाए। यह स्कोर देता है कि कितना कंटेंट हिलता है और कितनी दूर।

CLS कैसे सुधारें

इमेज और वीडियो पर width और height सेट करें, या CSS aspect-ratio इस्तेमाल करें, ताकि जगह आरक्षित रहे
तय साइज़ वाले कंटेनर से विज्ञापन, embed और iframe के लिए जगह आरक्षित करें
मौजूदा कंटेंट के ऊपर कंटेंट डालने से बचें, जैसे बैनर जो लोड होने के बाद पेज को नीचे धकेलते हैं
font-display: swap सावधानी से इस्तेमाल करें और मुख्य वेब फ़ॉन्ट प्रीलोड करें, या फ़ॉलबैक फ़ॉन्ट मेट्रिक्स इस्तेमाल करें ताकि टेक्स्ट दोबारा न खिसके
transform से एनिमेट करें, top या height जैसी प्रॉपर्टी से नहीं जो लेआउट ट्रिगर करती हैं

एक व्यावहारिक वर्कफ़्लो

यह देखने के लिए Search Console की Core Web Vitals रिपोर्ट जाँचें कि URL के कौन से समूह किस मेट्रिक पर फ़ेल होते हैं
हर फ़ेल होने वाले समूह से एक प्रतिनिधि URL चुनें
क्या धीमा है, यह पता करने के लिए लैब टेस्ट चलाएँ
टेम्पलेट लेवल पर ठीक करें – ज़्यादातर समस्याएँ एक ही लेआउट इस्तेमाल करने वाले हर पेज को प्रभावित करती हैं
वैलिडेट करें: Search Console में डिप्लॉय करने के बाद validation शुरू करें; सुधार दिखाने में फ़ील्ड डेटा को 28 दिन तक लगते हैं

पेज स्पीड टेस्ट

किसी भी पेज के लिए Lighthouse परफ़ॉर्मेंस स्कोर, लैब मेट्रिक्स और असली यूज़र के Core Web Vitals।

पेज स्पीड टेस्ट खोलें

Core Web Vitals रैंकिंग पर कितना असर डालते हैं?

Google साफ़ कह चुका है कि पेज एक्सपीरियंस कई संकेतों में से एक है, और प्रासंगिकता और मददगार कंटेंट ज़्यादा मायने रखते हैं। कमज़ोर कंटेंट वाला तेज़ पेज किसी बेहतरीन पेज से आगे रैंक नहीं करेगा। लेकिन जब पेज लगभग बराबर प्रासंगिक हों, तो बेहतर अनुभव मदद कर सकता है – और तेज़ पेज लगातार बेहतर कन्वर्ट करते हैं, जो रैंकिंग से अलग भी मायने रखता है।

प्लेटफ़ॉर्म के हिसाब से टिप्स

WordPress

सर्वर रिस्पॉन्स टाइम घटाने के लिए कैशिंग प्लगइन या होस्ट-लेवल कैशिंग इस्तेमाल करें
हल्की थीम चुनें; भारी पेज बिल्डर अक्सर बहुत ज़्यादा CSS और JavaScript जोड़ते हैं
प्लगइन का ऑडिट करें: हर एक हर पेज पर स्क्रिप्ट जोड़ सकता है, जिससे INP को नुकसान होता है
ऐसा इमेज ऑप्टिमाइज़ेशन प्लगइन इस्तेमाल करें जो WebP या AVIF दे और width और height एट्रिब्यूट जोड़े
जिन थर्ड-पार्टी स्क्रिप्ट की हर पेज पर ज़रूरत नहीं, उन्हें टालें या हटाएँ

Shopify

इंस्टॉल किए गए ऐप की समीक्षा करें – कई इस्तेमाल न होने पर भी हर पेज पर स्क्रिप्ट डालते हैं
थीम के बिल्ट-इन रिस्पॉन्सिव इमेज फ़ीचर इस्तेमाल करें
होमपेज पर सेक्शन और स्लाइडर की संख्या सीमित करें
अपलोड करने से पहले इमेज कम्प्रेस और रीसाइज़ करें

कस्टम और JavaScript से भरी साइटें

server-side rendering या static generation इस्तेमाल करें ताकि कंटेंट JavaScript का इंतज़ार किए बिना दिखे
रूट के हिसाब से code-split करें और कंपोनेंट ज़रूरत पर लोड करें
web-vitals JavaScript लाइब्रेरी से असली यूज़र का INP मापें और उसे एनालिटिक्स में भेजें, ताकि आप देख सकें कि कौन से इंटरैक्शन धीमे हैं

असली यूज़र डेटा खुद मापना

Search Console और PageSpeed Insights इकट्ठा किया गया Chrome डेटा दिखाते हैं, लेकिन सिर्फ़ पर्याप्त ट्रैफ़िक वाले पेजों के लिए और देरी से। हर पेज और हर विज़िटर के Core Web Vitals देखने के लिए real-user monitoring (RUM) जोड़ें। ओपन-सोर्स web-vitals लाइब्रेरी विज़िटर के ब्राउज़र से LCP, INP और CLS रिपोर्ट करती है; आप ये वैल्यू Google Analytics 4 या किसी दूसरे एनालिटिक्स टूल में भेज सकते हैं। RUM यह भी दर्ज करता है कि कौन सा एलिमेंट LCP था और कौन सा इंटरैक्शन सबसे धीमा था – ठीक वही जो समस्या ठीक करने के लिए चाहिए।

Total Blocking Time और Speed Index पर एक टिप्पणी

Lighthouse Core Web Vitals के अलावा दूसरे मेट्रिक्स भी रिपोर्ट करता है। Total Blocking Time (TBT) मापता है कि लोडिंग के दौरान main thread कितनी देर ब्लॉक रहा और यह INP से जुड़ा है। First Contentful Paint (FCP) दर्शाता है कि पहली बार कुछ भी कब दिखा। Speed Index मापता है कि दिखने वाला हिस्सा कितनी जल्दी भरता है। ये उपयोगी डायग्नोस्टिक हैं लेकिन खुद Core Web Vitals नहीं हैं।

आम भ्रांतियाँ

“रैंक करने के लिए PageSpeed में 100 स्कोर ज़रूरी है।” नहीं। पेज एक्सपीरियंस के लिए फ़ील्ड डेटा में Core Web Vitals की सीमाएँ पास करना मायने रखता है, और प्रासंगिकता कहीं ज़्यादा मायने रखती है।
“Core Web Vitals सिर्फ़ Google के लिए मायने रखते हैं।” तेज़, ज़्यादा स्थिर पेज हर विज़िटर के लिए कन्वर्ज़न और संतुष्टि बढ़ाते हैं, चाहे वे आपकी साइट पर कहीं से भी आए हों।
“ज़्यादा कैशिंग प्लगइन जोड़ने से मदद मिलती है।” कई कैशिंग या ऑप्टिमाइज़ेशन प्लगइन एक साथ लगाने से अक्सर टकराव होता है। एक अच्छी तरह कॉन्फ़िगर किया गया समाधान इस्तेमाल करें।

मुख्य बातें

Core Web Vitals लोडिंग (LCP), रिस्पॉन्सिवनेस (INP) और विज़ुअल स्थिरता (CLS) मापते हैं।
असली विज़िट के 75वें पर्सेंटाइल पर अच्छी सीमाएँ हैं LCP ≤ 2.5 s, INP ≤ 200 ms और CLS ≤ 0.1।
असली Chrome यूज़र का फ़ील्ड डेटा ही मायने रखता है; लैब टेस्ट समस्याओं का पता लगाने के लिए हैं।
LCP आमतौर पर तेज़ सर्वर और बेहतर ऑप्टिमाइज़ की गई हीरो इमेज से सुधरता है।
INP तब सुधरता है जब आप JavaScript, खासकर थर्ड-पार्टी स्क्रिप्ट, घटाते और तोड़ते हैं।
CLS तब सुधरता है जब आप इमेज, विज्ञापन और embed के लिए जगह आरक्षित करते हैं।

अक्सर पूछे जाने वाले सवाल

मेरे लैब और फ़ील्ड स्कोर अलग क्यों हैं?

लैब टेस्ट एक डिवाइस और नेटवर्क की नकल करते हैं। फ़ील्ड डेटा आपके असली विज़िटर के डिवाइस, नेटवर्क और व्यवहार को दर्शाता है, जिसमें वे इंटरैक्शन भी शामिल हैं जो लैब टेस्ट नहीं करते।

सुधार Search Console में दिखने में कितना समय लगता है?

फ़ील्ड डेटा पिछले 28 दिनों को कवर करता है, इसलिए किसी सुधार को पूरी तरह दिखने में चार हफ़्ते तक लगते हैं।

क्या Core Web Vitals डेस्कटॉप पर मायने रखते हैं?

हाँ। Google मोबाइल और डेस्कटॉप का अलग-अलग मूल्यांकन करता है। मोबाइल पर पास होना आमतौर पर ज़्यादा मुश्किल होता है क्योंकि डिवाइस और नेटवर्क धीमे होते हैं।

अच्छा PageSpeed स्कोर क्या है?

90 या उससे ऊपर अच्छा है। लेकिन स्कोर एक लैब सारांश है; पेज एक्सपीरियंस के लिए फ़ील्ड डेटा में Core Web Vitals पास करना मायने रखता है।

थीम

भाषा

ऑडिट

रिसर्च

टूल

सीखें

प्राथमिकताएँ

Core Web Vitals समझें: LCP, INP और CLS (और इन्हें कैसे सुधारें)