Core Web Vitals असेसमेंट फ़ेल? LCP, INP और CLS कैसे सुधारें

संक्षिप्त उत्तर: Core Web Vitals असेसमेंट फ़ेल होने का मतलब है कि तीन मापदंडों में से कम से कम एक असली आगंतुकों के लिए अपनी सीमा चूक रहा है: LCP (लोडिंग) 2.5 सेकंड या उससे कम, INP (प्रतिक्रिया की गति) 200 मिलीसेकंड या उससे कम और CLS (दृश्य स्थिरता) 0.1 या उससे कम होना चाहिए, हर एक 75वें पर्सेंटाइल पर मापा गया। फ़ेल होने वाला मापदंड असली आगंतुकों के फ़ील्ड डेटा में ढूँढिए, लैब स्कोर में नहीं, और पहले उसी को ठीक कीजिए। Google कहता है कि उसके रैंकिंग सिस्टम Core Web Vitals इस्तेमाल करते हैं, पर अच्छे मान शीर्ष स्थान की गारंटी नहीं हैं।

“Core Web Vitals असेसमेंट फ़ेल” का मतलब क्या है?

Core Web Vitals, Google की Web Vitals पहल का वह हिस्सा हैं जो हर वेब पेज पर लागू होता है। web.dev तीन मापदंड गिनाता है, अनुभव के हर पहलू के लिए एक:

मान पेज लोड के 75वें पर्सेंटाइल पर आँके जाते हैं, मोबाइल और डेस्कटॉप के लिए अलग-अलग। सीधे शब्दों में: चार में से तीन विज़िट में मान अच्छा होना चाहिए, और फ़ोन तथा डेस्कटॉप का अपना-अपना फ़ैसला होता है। web.dev टूल्स से कहता है कि पेज को तभी पास गिनें जब वह तीनों मापदंडों के लक्ष्य 75वें पर्सेंटाइल पर पूरे करे। इसलिए एक लाल मापदंड फ़ेल होने के लिए काफ़ी है।

सीमा पर एक बारीक बात: web.dev INP और CLS के लिए “या कम” लिखता है, जबकि Google के Search दस्तावेज़ में “less than 200 milliseconds” और “less than 0.1” है, यानी “से कम”। रेखा से साफ़ नीचे का निशाना रखिए, तब यह फ़र्क़ मायने नहीं रखता।

एक बदलाव जानना ज़रूरी है: जैसा web.dev की घोषणा कहती है, मार्च 2024 में INP ने First Input Delay (FID) की जगह Core Web Vital के रूप में ले ली। जो गाइड अब भी FID गिनाती है, वह पुरानी है। इस लेख में नाम लिए सभी पेज हमने 4 नवंबर 2026 को पढ़े; web.dev का अवलोकन आख़िरी बार 31 अक्टूबर 2024 को अपडेट हुआ था।

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

Google के अनुसार हाँ, पर वह कोई वज़न नहीं बताता। Google का पेज अनुभव वाला पेज कहता है: “Core Web Vitals are used by our ranking systems.” वह Search में सफलता के लिए अच्छे मान की सलाह देता है, और जोड़ता है कि पेज अनुभव का कोई एक अकेला संकेत नहीं है।

उसी पेज में सीमाएँ भी उतनी ही साफ़ हैं। Search Console की Core Web Vitals रिपोर्ट या तीसरे पक्ष के टूल्स में अच्छे नतीजे “doesn't guarantee that your pages will rank at the top of Google Search results”, यानी इस बात की गारंटी नहीं देते कि आपके पेज Google Search के नतीजों में सबसे ऊपर होंगे। यह भी लिखा है कि सिर्फ़ SEO के लिए परफ़ेक्ट स्कोर के पीछे भागना आपके समय का सबसे अच्छा इस्तेमाल शायद न हो। Google हमेशा सबसे प्रासंगिक सामग्री दिखाने की कोशिश करता है, भले ही पेज का अनुभव ख़राब हो।

मापदंडों का वज़न कितना है, यह Google प्रकाशित नहीं करता, इसलिए हम भी कोई संख्या नहीं बताते। हमारी समझ, Google का कथन नहीं: सीमाओं को अपने आगंतुकों के लिए गुणवत्ता का पैमाना मानिए, तीनों को “अच्छे” में लाइए, और फिर अपना समय सामग्री पर वापस लगाइए। Google के मुख्य रैंकिंग सिस्टम आम तौर पर सामग्री को पेज-दर-पेज आँकते हैं, इसलिए हर ज़रूरी पेज-प्रकार जाँचिए।

लैब डेटा या फ़ील्ड डेटा: Core Web Vitals में कौन-सा गिना जाता है?

असेसमेंट फ़ील्ड डेटा पर आधारित है: असली विज़िट से लिए गए माप। Google की Chrome User Experience Report (CrUX) उन्हें असली Chrome उपयोगकर्ताओं से इकट्ठा करती है; PageSpeed Insights और Search Console की Core Web Vitals रिपोर्ट उन्हें दिखाती हैं। web.dev के अनुसार CrUX रिपोर्ट 28 दिन की अवधि को कवर करती है।

लैब डेटा तब बनता है जब पेज को एक नियंत्रित सेटअप में एक बार लोड किया जाता है: एक डिवाइस, एक नेटवर्क, एक जगह। कारण खोजने और रिलीज़ से पहले किसी सुधार को परखने के लिए यह आदर्श है, पर LCP गाइड चेताती है कि “lab tests alone may not be entirely representative”, यानी सिर्फ़ लैब टेस्ट पूरी तरह प्रतिनिधि नहीं हो सकते। जब दोनों में असहमति हो, तो LCP गाइड कहती है कि पहले असली उपयोगकर्ताओं के डेटा पर ध्यान दीजिए। उनके अलग होने की ठोस वजहें हैं:

• LCP का तत्व अलग हो सकता है। लैब रन हमेशा वही तत्व पाता है। असली विज़िट में स्क्रीन के आकार अलग होते हैं, लॉग-इन की सामग्री या A/B टेस्ट होते हैं।
• INP के लिए असली लोग चाहिए। Lighthouse और दूसरे लैब टूल पेज को बिना किसी के क्लिक किए लोड करते हैं, इसलिए INP नहीं माप सकते। Total Blocking Time (TBT) लैब में उसकी जगह है; TBT में सुधार INP में भी सुधार ला सकता है।
• CLS लोडिंग के बाद भी गिनता रहता है। लैब रन ज़्यादातर लोड ही देखते हैं। फ़ील्ड में, आगंतुकों के स्क्रॉल करते समय आने वाली सामग्री भी लेआउट खिसका सकती है।
• कैश असली आगंतुकों की मदद करता है। लैब टेस्ट आम तौर पर ख़ाली कैश से शुरू होते हैं, जबकि लौटने वाले आगंतुक और back/forward cache पेज को तेज़ी से लोड करते हैं।

अपने आँकड़े चार चरणों में कैसे पढ़ें:

1. अपना पता PageSpeed Insights में चलाइए। “Discover what your real users are experiencing” वाले हिस्से में फ़ील्ड डेटा है; “Diagnose performance issues” में लैब रन।
2. देखिए कि आप क्या देख रहे हैं। मोबाइल और डेस्कटॉप के बीच, और एक URL तथा पूरे origin के बीच बदलकर देखिए। अगर किसी URL के पास डेटा कम है, तो PageSpeed Insights उसकी जगह origin का डेटा दिखाता है।
3. वह मापदंड ढूँढिए जो 75वें पर्सेंटाइल पर अपनी रेखा के पार है। वही आपका फ़ेल होने वाला मापदंड है। ट्रैफ़िक कम हो तो फ़ील्ड डेटा नहीं होता; तब लैब मान इस्तेमाल कीजिए और web.dev की छोटी web-vitals लाइब्रेरी से अपने आगंतुकों को ख़ुद मापिए।
4. उस मापदंड का लैब डायग्नोस्टिक खोलिए और कारण देखिए, और पहले उसी एक चीज़ को ठीक कीजिए।

LCP कैसे सुधारें: सबसे बड़ा तत्व देर से आता है

LCP बताता है कि दिखने वाले हिस्से का सबसे बड़ा चित्र, टेक्स्ट ब्लॉक या वीडियो कब बनकर तैयार होता है। web.dev की LCP गाइड समय को चार हिस्सों में बाँटती है जो मिलकर LCP बनाते हैं: सर्वर का जवाब (TTFB), ब्राउज़र के LCP संसाधन को लोड करना शुरू करने से पहले की देरी, उस संसाधन के लोड होने का समय, और तत्व के बनकर दिखने तक की देरी। कुछ बदलने से पहले सबसे बड़ा हिस्सा ढूँढिए: एक हिस्सा छोटा करने से समय बस दूसरे में खिसक सकता है। संकुचित किया हुआ चित्र तब मदद नहीं करता जब तत्व किसी स्क्रिप्ट के लोड होने तक छिपा रहता है।

Chrome टीम की सबसे असरदार सुधारों की सूची में ये शामिल हैं:

1. LCP चित्र को आसानी से मिलने लायक़ बनाइए और उसे प्राथमिकता दीजिए। src या srcset वाला सामान्य <img> इस्तेमाल कीजिए, data-src नहीं जिसे JavaScript चाहिए। पेज को सिर्फ़ ब्राउज़र में बनाने के बजाय सर्वर-साइड रेंडरिंग को चुनिए। fetchpriority="high" जोड़िए और सिर्फ़ इसी एक चित्र से loading="lazy" हटाइए।
2. सर्वर का जवाब छोटा कीजिए। सामग्री अपने आगंतुकों के पास से परोसिए और कैश कीजिए, आम तौर पर CDN से।

वही tag LCP सँभालता है और, अपने आकार के ज़रिए, CLS भी:

<!-- मुख्य चित्र: HTML में, ऊँची प्राथमिकता, lazy नहीं, आकार के साथ -->
<img src="/img/hero.webp" width="1200" height="630" alt="छोटा विवरण" fetchpriority="high">

<!-- पेज में नीचे के चित्र: यहाँ lazy loading ठीक है -->
<img src="/img/team.webp" width="600" height="400" alt="छोटा विवरण" loading="lazy">

INP कैसे सुधारें: पेज देर से जवाब देता है

INP विज़िट के दौरान हर क्लिक, टैप और कुंजी दबाने को देखता है और लगभग सबसे धीमे वाले को रिपोर्ट करता है (बहुत ज़्यादा इंटरैक्शन वाले पेजों में अपवाद छोड़ दिए जाते हैं)। माउस घुमाना और स्क्रॉल करना नहीं गिना जाता। INP गाइड के अनुसार हर इंटरैक्शन के तीन हिस्से हैं: इनपुट की देरी, event handler के चलने का समय, और अगला फ़्रेम दिखने तक की देरी। आम दोषी JavaScript है जो main thread को व्यस्त रखती है। Chrome टीम के मुख्य सुधार:

1. लंबे tasks तोड़िए। 50 मिलीसेकंड से लंबा task main thread को रोकता है। नियंत्रण बार-बार लौटाइए: जहाँ ब्राउज़र समर्थन करे वहाँ scheduler.yield(), पुराने तरीक़े के रूप में setTimeout।
2. कम JavaScript भेजिए। Chrome DevTools के coverage टूल से बेकार कोड ढूँढिए, जो कोड शुरू में नहीं चाहिए उसे अलग कीजिए, और अपने tag manager के पुराने tag साफ़ कीजिए।
3. बड़े रेंडरिंग अपडेट से बचिए। DOM छोटा रखिए, forced layout से बचिए और स्क्रीन के बाहर की सामग्री के लिए CSS containment इस्तेमाल कीजिए।

CLS कैसे सुधारें: लेआउट उछलता है

CLS की कोई इकाई नहीं है। वह मिलाता है कि कितनी दिखने वाली सामग्री खिसकी और कितनी दूर खिसकी। फ़ील्ड में वह पूरी विज़िट पर गिनता है, पर उपयोगकर्ता के किसी इंटरैक्शन के 500 मिलीसेकंड के भीतर के खिसकाव छोड़ दिए जाते हैं। web.dev की CLS गाइड आम कारण गिनाती है: बिना आकार के चित्र, विज्ञापन, बिना आकार के embed और iframe, बाद में डाली गई सामग्री और web fonts। जो मदद करता है:

• जगह सुरक्षित रखिए। चित्रों और वीडियो को width और height दीजिए, या CSS की aspect-ratio प्रॉपर्टी इस्तेमाल कीजिए। अनजान आकार की सामग्री के लिए सोच-समझकर रखी गई min-height, शून्य के डिफ़ॉल्ट से बेहतर है।
• transform से एनिमेट कीजिए। top, left या margin को एनिमेट करने से लेआउट खिसकता है। भीतर सरकने वाले कुकी बैनर इसका आम उदाहरण हैं।
• back/forward cache को काम करने दीजिए। वह पूरी तरह बने हुए पेज लौटा देता है। आम रुकावटें no-store कैशिंग निर्देश और unload event listener हैं।
• web fonts सँभालिए। font-display: optional, size-adjust से मेल खाते fallback fonts और ज़रूरी fonts को पहले से लोड करना, ये सब font से जुड़े खिसकाव घटाते हैं।

SEOgrinder Core Web Vitals को कैसे जाँचता है

SEOgrinder हमारा टूल है; हम इसे बनाते हैं। SEOgrinder में कोई सार्वजनिक पता डालिए और गति के आँकड़े Google PageSpeed Insights से आते हैं, फ़ोन और डेस्कटॉप दोनों के लिए। “Core Web Vitals” कार्ड LCP और CLS को Lighthouse के लैब रन से दिखाता है और INP को असली आगंतुकों से, और एक अलग डिब्बे में पिछले 28 दिनों का असली उपयोगकर्ता डेटा दिखता है। अगर Google के पास पेज का डेटा कम है, तो रिपोर्ट अंदाज़ा लगाने के बजाय यही कहती है। “मोबाइल पर असली आगंतुकों को सामग्री दिखने में … लगते हैं” जैसे कार्य मापदंड, मान और सुधार बताते हैं। सर्वर का धीमा जवाब, जो LCP में जुड़ता है, “सर्वर की प्रतिक्रिया धीमी है” नाम के अपने कार्य में आता है।

सीमाएँ: SEOgrinder Google के आँकड़े पढ़ता है और आपकी अपनी असली-उपयोगकर्ता निगरानी की जगह नहीं लेता। वह रैंकिंग नहीं मापता। अगर गति के माप के लिए Google का दैनिक कोटा ख़त्म हो गया हो, तो रिपोर्ट उसके बिना आती है।

आम ग़लतियाँ

• सिर्फ़ लैब स्कोर पर भरोसा। वह INP नहीं माप सकता और आगंतुकों के अनुभव से अलग दिख सकता है। असली आगंतुकों के मान से शुरू कीजिए।
• सिर्फ़ एक डिवाइस जाँचना। मोबाइल और डेस्कटॉप अलग-अलग आँके जाते हैं।
• मुख्य चित्र को lazy-load करना। LCP चित्र पर loading="lazy" देरी जोड़ता है।
• चित्र का आकार छोड़ देना। width और height के बिना ब्राउज़र जगह सुरक्षित नहीं रख सकता।
• LCP का ग़लत हिस्सा सुधारना। चित्र तभी संकुचित कीजिए जब विभाजन दिखाए कि लोडिंग समय ही समस्या है।
• तुरंत नतीजे की उम्मीद। फ़ील्ड डेटा 28 दिन का होता है, इसलिए धीरे-धीरे बदलता है। सुधार के तुरंत बाद लैब रन देखिए, और असली आगंतुकों के आँकड़े अगले हफ़्तों में।

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

Core Web Vitals का अच्छा स्कोर क्या है?

कोई एक स्कोर नहीं है। पेज तब पास होता है जब 75वें पर्सेंटाइल पर LCP 2.5 सेकंड या कम, INP 200 मिलीसेकंड या कम और CLS 0.1 या कम हो। Lighthouse से आपको जो 0 से 100 की संख्या पता है, वह लैब का आँकड़ा है और एक अलग चीज़ है।

मेरी साइट के लिए PageSpeed Insights असली उपयोगकर्ताओं का डेटा क्यों नहीं दिखाता?

आम तौर पर CrUX के रिपोर्ट करने के लिए विज़िट बहुत कम होती हैं। ऐसे में web.dev सुझाव देता है कि असली आगंतुकों का अपना माप जोड़िए। तब तक लैब मानों से काम चलाइए।

क्या मुझे परफ़ेक्ट स्कोर चाहिए?

नहीं। लक्ष्य पास होना है। Google ख़ुद कहता है कि सिर्फ़ SEO के कारणों से परफ़ेक्ट स्कोर के पीछे भागना आपके समय का सबसे अच्छा इस्तेमाल शायद न हो।

आपका अगला कदम

अपना सबसे ज़रूरी पेज SEOgrinder से चलाइए, “Core Web Vitals” कार्ड खोलिए और पहले असली आगंतुकों के मान देखिए। जो एक मापदंड फ़ेल है उसे ठीक कीजिए, “दोबारा जाँचें” दबाइए और लैब मान पढ़िए। बड़ी तस्वीर हमारी SEO audit checklist में है।

यह भी पढ़ें

• Google पर रैंक बढ़ाएँ: Google ख़ुद जो 3 बातें सुझाता है
• internal linking: अनाथ पेज कैसे खोजें और क्लिक गहराई कैसे घटाएँ
• JSON-LD structured data: कॉपी करके आज़माने लायक़ 2 उदाहरण