2026 में Core Web Vitals: रैंकिंग पर असल में क्या असर डालता है

Core Web Vitals आज क्या मापते हैं

Core Web Vitals तीन मेट्रिक हैं जो बताते हैं कि असली विज़िटर को पेज कैसा लगता है। Largest Contentful Paint (LCP) लोडिंग मापता है: मुख्य इमेज या टेक्स्ट ब्लॉक दिखने में कितना समय लगता है। Interaction to Next Paint (INP) रिस्पॉन्सिवनेस मापता है: टैप, क्लिक या की दबाने के बाद पेज कितनी जल्दी दिखाई देने वाली प्रतिक्रिया देता है। Cumulative Layout Shift (CLS) स्थिरता मापता है: लोड होते समय कंटेंट कितना खिसकता है।

पेज तब पास होता है जब कम से कम 75% विज़िट “अच्छी” सीमा में हों: LCP 2.5 सेकंड या कम, INP 200 मिलीसेकंड या कम और CLS 0.1 या कम। मोबाइल और डेस्कटॉप अलग-अलग परखे जाते हैं, और मोबाइल लगभग हमेशा ज़्यादा मुश्किल होता है।

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

रैंकिंग पर इनका कितना असर है?

Core Web Vitals, Google के पेज एक्सपीरियंस संकेतों का हिस्सा हैं। ये प्रासंगिकता से ऊपर नहीं हैं: सबसे अच्छे जवाब वाला धीमा पेज, कमज़ोर जवाब वाले तेज़ पेज से फिर भी आगे रहेगा। ये एक जैसी गुणवत्ता वाले पेजों के बीच और सबसे ज़्यादा कन्वर्ज़न में मायने रखते हैं — विज़िटर धीमे, हिलते पेज छोड़ देते हैं, रैंकिंग चाहे जो हो।

इसलिए हम इन मेट्रिक को पहले बिज़नेस मेट्रिक और फिर SEO मेट्रिक मानते हैं। तेज़ पेज ज़्यादा बेचते हैं, ज़्यादा पूछताछ लाते हैं और पेड ट्रैफ़िक सस्ता करते हैं।

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

Lighthouse और PageSpeed Insights के लैब स्कोर एक धीमे किए गए डिवाइस पर एक सिम्युलेटेड विज़िट चलाते हैं। ये डीबगिंग में काम आते हैं, लेकिन Google, Chrome User Experience Report (CrUX) के फ़ील्ड डेटा पर रैंक करता है, जो असली Chrome यूज़र्स से 28 दिनों में इकट्ठा होता है।

Search Console की Core Web Vitals रिपोर्ट से शुरू करें और देखें कि कौन से URL समूह किस मेट्रिक में फ़ेल हैं। फिर एक URL के फ़ील्ड आँकड़ों के लिए PageSpeed Insights और कारण ढूँढने के लिए Chrome DevTools का Performance पैनल इस्तेमाल करें।

LCP ठीक करना

ज़्यादातर LCP समस्याएँ चार जगहों से आती हैं: धीमा सर्वर रिस्पॉन्स, देर से मिलने वाली मुख्य इमेज, रेंडर रोकने वाले CSS और फ़ॉन्ट, या बस बहुत भारी इमेज।

• Time to First Byte को लगभग 800 मिलीसेकंड से नीचे लाएँ: अनाम विज़िटर के लिए फ़ुल-पेज कैश, CDN और तेज़ डेटाबेस क्वेरी।
• LCP इमेज को कभी lazy-load न करें। उसे fetchpriority="high" दें, और अगर वह CSS में सेट है तो preload करें।
• एक बड़े JPEG की जगह srcset और sizes के साथ सही आकार में AVIF या WebP दें।
• ज़रूरी CSS इनलाइन करें और बाकी बिना रोके लोड करें; फ़ॉन्ट ख़ुद होस्ट करें और font-display: swap इस्तेमाल करें।

INP ठीक करना

INP लगभग हमेशा JavaScript की समस्या है। जब मेन थ्रेड किसी लंबे काम में व्यस्त हो — 50 मिलीसेकंड से ज़्यादा का कोई भी काम — तो ब्राउज़र उसके ख़त्म होने तक यूज़र के टैप का जवाब नहीं दे सकता।

पहले थर्ड-पार्टी स्क्रिप्ट जाँचें: चैट विजेट, हीटमैप, A/B टेस्टिंग टूल और कई टैग कंटेनर अक्सर सैकड़ों मिलीसेकंड जोड़ते हैं। इन्हें इंटरैक्शन के बाद या सिर्फ़ कुछ पेजों पर लोड करें। अपने कोड में इवेंट हैंडलर छोटे रखें, इनपुट हैंडलर पर debounce लगाएँ, और लंबे काम को छोटे हिस्सों में बाँटें ताकि ब्राउज़र बीच में पेंट कर सके। बहुत बड़ा DOM (कई हज़ार एलिमेंट) भी हर इंटरैक्शन धीमा करता है, जो पेज बिल्डर में आम है।

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

CLS ठीक करना

• इमेज, वीडियो और iframe पर हमेशा width और height (या aspect-ratio) दें।
• विज्ञापन, एम्बेड और कुकी बैनर के लिए पहले से जगह रखें, ताकि लोड होने पर कंटेंट नीचे न धकेला जाए।
• पेज रेंडर होने के बाद मौजूदा कंटेंट के ऊपर बैनर या सूचना न डालें।
• मिलते-जुलते मेट्रिक वाले फ़ॉलबैक फ़ॉन्ट (size-adjust) इस्तेमाल करें, ताकि वेब फ़ॉन्ट आने पर टेक्स्ट न खिसके।

Laravel और WordPress की ख़ास बातें

Laravel में जल्दी फ़ायदे देने वाले कदम हैं: प्रोडक्शन कैश (php artisan config:cache, route:cache, view:cache), OPcache, कैश और सेशन के लिए Redis, और पहले बाइट को धीमा करने वाली N+1 क्वेरी हटाने के लिए eager loading। Vite से एसेट बनाएँ ताकि CSS और JavaScript मिनिफ़ाई और वर्ज़न हों, और ईमेल व API कॉल जैसे धीमे काम क्यू में भेजें।

WordPress में ज़्यादातर समस्याएँ प्लगइन से आती हैं। बेकार प्लगइन हटाएँ, अच्छा पेज कैश इस्तेमाल करें (LiteSpeed सर्वर पर LiteSpeed Cache बहुत अच्छा काम करता है), अपलोड पर इमेज ऑप्टिमाइज़ करें, PHP को सपोर्टेड 8.x वर्ज़न पर रखें और भारी पेज बिल्डर से सावधान रहें।

मापें, फिर इंतज़ार करें

ओपन-सोर्स web-vitals लाइब्रेरी जोड़ें ताकि असली LCP, INP और CLS मान GA4 या आपके अपने एंडपॉइंट पर जाएँ — इससे आप CrUX का इंतज़ार किए बिना कुछ दिनों में बदलाव देख पाएँगे। Search Console की रिपोर्ट 28 दिन की चलती अवधि इस्तेमाल करती है, इसलिए सुधार के बाद स्टेटस हरा होने में लगभग चार हफ़्ते लगते हैं। नया डेटा आने पर वहीं सुधार को वैलिडेट करें।

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