Core Web Vitals के साथ एक ख़ास तरह की झुंझलाहट जुड़ी है। आप Search Console खोलते हैं और लाल रंग में "Poor URLs" की चेतावनी देखते हैं। आप टेस्ट चलाते हैं और 94 का स्कोर मिलता है, सब हरा। आप कुछ नहीं बदलते, फिर टेस्ट करते हैं, और 71 मिलता है। इस बीच कहीं कोई रिपोर्ट कहती है कि आपके असली यूज़र्स का अनुभव ख़राब है, और आपको समझ नहीं आता कि किस आँकड़े पर भरोसा करें।
आप कुछ ग़लत नहीं कर रहे। Core Web Vitals सचमुच उलझाने वाले हैं, जब तक आप यह न समझ लें कि डेटा दो तरह का होता है, मेट्रिक तीन होते हैं, और Google उन्हें आँकने का एक बहुत ख़ास तरीक़ा अपनाता है। एक बार यह समझ आ जाए, तो उन्हें ठीक करना अंदाज़ेबाज़ी नहीं, बल्कि एक व्यावहारिक चेकलिस्ट बन जाता है।
तीन मेट्रिक, तीन एहसास
हर Core Web Vital कुछ ऐसा मापता है जिसे विज़िटर सच में महसूस करता है।
| मेट्रिक | यह क्या मापता है | विज़िटर क्या महसूस करता है | अच्छा | ख़राब |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | कंटेंट का सबसे बड़ा हिस्सा कब दिखता है | "क्या यह पेज लोड हो रहा है?" | 2.5 s या कम | 4 s से ज़्यादा |
| Interaction to Next Paint (INP) | पेज टैप, क्लिक और टाइपिंग पर कितनी जल्दी प्रतिक्रिया देता है | "क्या मेरे टैप से कुछ हुआ?" | 200 ms या कम | 500 ms से ज़्यादा |
| Cumulative Layout Shift (CLS) | लोड होते समय लेआउट कितना उछलता है | "बटन खिसक क्यों गया?" | 0.1 या कम | 0.25 से ज़्यादा |
अगर आपने First Input Delay (FID) के बारे में सुना है, तो उसे भूल सकते हैं। मार्च 2024 में Core Web Vital के रूप में INP ने उसकी जगह ले ली, क्योंकि FID सिर्फ़ पहला इंटरैक्शन देखता था, जबकि INP विज़िट के दौरान हर इंटरैक्शन को गिनता है। कोई पेज पहले टैप पर फुर्तीला और दसवें पर सुस्त लग सकता है, और INP इसे पकड़ लेता है।
फ़ील्ड डेटा बनाम लैब डेटा: आपके आँकड़े मेल क्यों नहीं खाते
ज़्यादातर उलझन की जड़ यही है, इसलिए इसे ध्यान से समझना फ़ायदेमंद है।
फ़ील्ड डेटा उन असली Chrome यूज़र्स से आता है जिन्होंने पिछले 28 दिनों में पेज देखा, और यह Chrome User Experience Report में इकट्ठा होता है। यह असली फ़ोन, असली नेटवर्क और असली व्यवहार दिखाता है। Google 75वाँ पर्सेंटाइल इस्तेमाल करता है: चार में से तीन विज़िट कम से कम इतनी अच्छी होनी चाहिए। Search Console यही डेटा दिखाता है और पेज एक्सपीरियंस के लिए यही डेटा मायने रखता है।
लैब डेटा उसी समय चलाए गए एक टेस्ट से आता है, आम तौर पर Lighthouse, एक सिम्युलेटेड डिवाइस और कनेक्शन पर। यह दोहराया जा सकता है और डीबग करने के लिए बढ़िया है, लेकिन यह नियंत्रित हालात में एक विज़िट है, आपके असली दर्शक नहीं।
ये दोनों अच्छी वजहों से अलग होते हैं:
- आपके असली विज़िटर टेस्ट में सिम्युलेट किए गए फ़ोन से पुराने फ़ोन इस्तेमाल कर सकते हैं, या कहीं तेज़ फ़ोन।
- लैब टेस्ट सीधे INP नहीं माप सकता, क्योंकि लैब रन के दौरान कोई कुछ टैप नहीं करता। इसकी जगह यह Total Blocking Time बताता है, जो इससे काफ़ी जुड़ा हुआ है।
- फ़ील्ड डेटा 28 दिनों की लगातार आगे खिसकती अवधि का होता है, इसलिए कल किया सुधार आज उसमें नहीं दिखता।
- सर्वर के रिस्पॉन्स टाइम, थर्ड-पार्टी स्क्रिप्ट और टेस्ट मशीन के लोड की वजह से लैब स्कोर हर रन में बदलते हैं।
व्यावहारिक नियम: सुधार ढूँढने और पक्का करने के लिए लैब डेटा इस्तेमाल करें, और यह जानने के लिए फ़ील्ड डेटा कि असली यूज़र ख़ुश हैं या नहीं। Core Web Vitals Checker किसी भी सार्वजनिक पेज के लिए, मोबाइल या डेस्कटॉप पर, दोनों को साथ-साथ दिखाता है, हर नतीजे के बगल में Google के टारगेट के साथ।
धीमा Largest Contentful Paint ठीक करना
LCP आम तौर पर हीरो इमेज, बड़ी हेडिंग या बैनर होता है। यह चार में से किसी वजह से धीमा होता है, और ये वजहें आपस में जुड़ती जाती हैं।
धीमा सर्वर रिस्पॉन्स
जब तक सर्वर HTML नहीं भेजता, कुछ भी नहीं दिख सकता। अगर Time to First Byte 1.5 सेकंड है, तो 2.5 सेकंड का LCP लगभग असंभव है। Website Speed Tester से अपना सर्वर रिस्पॉन्स जाँचें; अगर यह 600 ms से ज़्यादा है, तो वहीं से शुरू करें। सर्वर रिस्पॉन्स टाइम घटाने की हमारी गाइड कैशिंग, होस्टिंग और रीडायरेक्ट के सुधार बताती है।
बहुत बड़ी हीरो इमेज
1200 पिक्सेल चौड़ाई पर दिखाई गई 3 MB की फ़ोटो मोबाइल पर सेकंडों बर्बाद करती है। इसे उतने साइज़ पर रीसाइज़ करें जितने पर यह असल में दिखती है, और WebP जैसा आधुनिक फ़ॉर्मेट इस्तेमाल करें। Image Resizer दोनों काम एक ही क़दम में, आपके ब्राउज़र में करता है।
इमेज देर से मिलती है
अगर हीरो इमेज CSS बैकग्राउंड के रूप में लगी है या JavaScript से डाली जाती है, तो ब्राउज़र उसे देर से ढूँढता है। मुख्य विज़ुअल के लिए सामान्य image एलिमेंट इस्तेमाल करें, उसे lazy-load न करें, और उसे fetchpriority="high" देने पर विचार करें।
रेंडर रोकने वाली CSS और फ़ॉन्ट
बड़ी स्टाइलशीट और वेब फ़ॉन्ट पहला पेंट रोक सकते हैं। बेकार CSS हटाएँ, फ़ॉन्ट font-display: swap के साथ लोड करें, और ऐसे कई फ़ॉन्ट परिवार लोड करने से बचें जिन्हें आप मुश्किल से इस्तेमाल करते हैं।
ख़राब Interaction to Next Paint ठीक करना
INP का संबंध JavaScript से है जो main thread को व्यस्त रखता है। जब कोई टैप करता है, तो ब्राउज़र मौजूदा टास्क ख़त्म होने तक जवाब नहीं दे सकता।
- पहले थर्ड-पार्टी स्क्रिप्ट जाँचें। चैट विजेट, heatmap, tag manager और विज्ञापन स्क्रिप्ट अक्सर दोषी होते हैं। जो इस्तेमाल नहीं करते उसे हटाएँ, और बाक़ी को पेज के इंटरैक्टिव होने के बाद लोड करें।
- लंबे टास्क तोड़ें। 50 ms से लंबा कोई भी एक टास्क जवाब में देरी करता है। भारी काम को छोटे टुकड़ों में बाँटने से ब्राउज़र उनके बीच जवाब दे पाता है।
- तुरंत प्रतिक्रिया दें। बटन की स्थिति तुरंत अपडेट करें या spinner दिखाएँ, फिर भारी काम करें। 100 ms के अंदर दिखने वाली प्रतिक्रिया तेज़ लगती है, भले ही नतीजे में ज़्यादा समय लगे।
- बहुत बड़े पेजों से सावधान। बहुत बड़े DOM, जैसे हज़ारों एलिमेंट वाली प्रोडक्ट लिस्टिंग, हर अपडेट को धीमा करते हैं। लंबी लिस्ट को पेजों में बाँटें या virtualise करें।
चेकर के लैब हिस्से में ऊँचा Total Blocking Time आपका सबसे अच्छा संकेत है कि फ़ील्ड में INP पर असर पड़ेगा।
ज़्यादा Cumulative Layout Shift ठीक करना
CLS सबसे आसानी से ठीक होने वाला मेट्रिक है और अक्सर विज़िटर्स को सबसे ज़्यादा चिढ़ाने वाला भी। यह तब होता है जब कोई कंटेंट दिखता है और दूसरे कंटेंट को धकेल देता है।
- हर इमेज और वीडियो को डाइमेंशन दें।
widthऔरheightएट्रिब्यूट (या CSS aspect ratio) सेट करें ताकि फ़ाइल लोड होने से पहले ब्राउज़र जगह रख ले। - विज्ञापनों और एम्बेड के लिए जगह रखें। विज्ञापन स्लॉट और iframe को एक तय न्यूनतम ऊँचाई दें, ख़ाली होने पर भी।
- मौजूदा कंटेंट के ऊपर कंटेंट न डालें, जैसे कुकी बार या प्रमोशन जो लोड होने के बाद पेज को नीचे धकेल दे। इसकी जगह उसे ऊपर overlay करें।
- फ़ॉन्ट सावधानी से लोड करें। वेब फ़ॉन्ट से बहुत चौड़ा या पतला fallback फ़ॉन्ट, फ़ॉन्ट आने पर टेक्स्ट को फिर से जमने पर मजबूर करता है।
अगर आप डिज़ाइन बनाते समय placeholder इमेज इस्तेमाल करते हैं, तो उन्हें आख़िरी इमेज जितने ही डाइमेंशन दें; हमारी placeholder इमेज गाइड बताती है कि बिना shift पैदा किए उन्हें कैसे बदलें।
काम का एक व्यावहारिक क्रम
जब सब कुछ लाल हो, तो एक क्रम होना मदद करता है।
- पहले मोबाइल वर्शन टेस्ट करें। Google पेजों का मोबाइल वर्शन इस्तेमाल करता है, और समस्याएँ फ़ोन पर ही सबसे बुरी होती हैं।
- सर्वर ठीक करें। धीमा Time to First Byte बाक़ी सब कुछ रोके रखता है।
- LCP एलिमेंट ठीक करें। आम तौर पर एक इमेज, एक बदलाव, बड़ा सुधार।
- लेआउट shift ठीक करें। ज़्यादातर इमेज, विज्ञापनों और एम्बेड पर डाइमेंशन।
- JavaScript कम करें। INP के लिए सबसे धीमा लेकिन सबसे क़ीमती काम।
- लैब में पुष्टि करें, फिर फ़ील्ड का इंतज़ार करें। लैब स्कोर आपका सुधार तुरंत दिखाता है। असली यूज़र्स के डेटा को बराबरी पर आने में चार हफ़्ते तक लगते हैं।
SEO के लिए Core Web Vitals कितने मायने रखते हैं?
सच कहें तो: ये मायने रखते हैं, लेकिन जादू नहीं हैं। Core Web Vitals Google के पेज एक्सपीरियंस सिग्नल का हिस्सा हैं, और ये आम तौर पर तब फ़र्क़ डालते हैं जब प्रतिस्पर्धी पेज लगभग बराबर प्रासंगिक और काम के हों। हल्के कंटेंट वाला तेज़ पेज उस धीमे पेज से ऊपर रैंक नहीं करेगा जो सवाल का कहीं बेहतर जवाब देता है।
इन्हें ठीक करने की बेहतर वजह यह है कि ये असली झुंझलाहट को बताते हैं। जो पेज अपना मुख्य कंटेंट जल्दी लोड करता है, तुरंत प्रतिक्रिया देता है और उछलता नहीं, वह इस्तेमाल करने में बस ज़्यादा सुखद होता है। विज़िटर ज़्यादा देर रुकते हैं, ज़्यादा पढ़ते हैं और लौटकर आते हैं।
आज कहाँ से शुरू करें
अपना सबसे ज़रूरी पेज चुनें, शायद होमपेज या आपका सबसे बड़ा लैंडिंग पेज, और उसे मोबाइल पर Core Web Vitals Checker से जाँचें। देखें कि कौन सा मेट्रिक सबसे ख़राब है और ऊपर के उससे जुड़े हिस्से पर काम करें। एक चीज़ ठीक करें, लैब नतीजे में उसकी पुष्टि करें, और अगली पर बढ़ें।
Core Web Vitals में प्रगति शायद ही कभी एक बड़े बदलाव से आती है। यह सही क्रम में किए गए कुछ छोटे, भरोसेमंद सुधारों से आती है।
