2026 में CORE WEB VITALS

2026 में परफॉर्मेंस का काम दो शिविरों में बँटा है। प्रतिक्रियाशील शिविर व्यक्तिगत पृष्ठों को एक बार ट्यून करता है जब वे एक सीमा के नीचे गिरते हैं। संरचनात्मक शिविर परफॉर्मेंस को फ्रेमवर्क विकल्प, डिज़ाइन सिस्टम, डिप्लॉयमेंट पाइपलाइन, और कंटेंट अनुशासन में बनाता है ताकि परफॉर्मेंस काम के डिफ़ॉल्ट परिणाम हों, न कि एक ऑप्टिमाइज़ेशन पास जो बाद में होता है। हर साइट जो मैंने दीर्घकालीन सफल होते देखी है, वह संरचनात्मक शिविर में है।

यह गाइड संरचनात्मक दृष्टिकोण है। साइटों से ठोस नंबर जो मैंने शिप किए हैं, वास्तविक जाँचें जो मैं चलाता हूँ, सबसे महँगी गलतियाँ जो मैंने की हैं, और पारंपरिक सलाह के वे भाग जो व्यवहार में गलत साबित हुए। CrUX से फील्ड डेटा हमेशा PageSpeed Insights से लैब डेटा को हराता है, इसलिए नीचे दिए गए अधिकांश नंबर 75वें प्रतिशतक पर वास्तविक उपयोगकर्ताओं से आते हैं।

LCP (Largest Contentful Paint)

सबसे बड़े above-the-fold एलिमेंट के रेंडर होने तक का समय। लक्ष्य: 75वें percentile पर 2.5 सेकंड से कम। सबसे अधिक cited Core Web Vital, अक्सर एक बार जब आप LCP एलिमेंट को सही तरीके से identify कर लें तो ठीक करना सबसे आसान होता है। अधिकांश sites में image या hero text block LCP एलिमेंट होता है; fix लगभग हमेशा image को preload करना, इसे सही तरीके से size करना, और यह सुनिश्चित करना है कि कोई JavaScript render को block न करे।

CLS (Cumulative Layout Shift)

पेज content कितना unexpectedly शिफ्ट होता है load के दौरान। लक्ष्य: 0.1 से कम। यह metric अक्सर lazy-loaded images बिना explicit width और height के, ads को पहले render के बाद inject करने से, या web fonts को different metrics वाले fallback के साथ swap करने से break होता है। अधिकांश cases में fold के ऊपर हर visual element पर explicit dimensions के बारे में disciplined होकर solve किया जा सकता है।

INP (Interaction to Next Paint)

पेज lifetime के दौरान experienced सबसे slow interaction time। लक्ष्य: 200ms से कम। March 2024 में FID की जगह लिया। hardest CWV metric को game करने के लिए, क्योंकि यह long-running tasks पर JavaScript के साथ real user friction को surface करता है। heavy client JavaScript वाले sites लगभग हमेशा यहां struggle करते हैं। fix कम JavaScript ship करना, long tasks को smaller chunks में break करना, और non-urgent work के लिए requestIdleCallback का उपयोग करना है।

TTFB (Time to First Byte)

किसी भी rendering शुरू होने से पहले server response time। लक्ष्य: 600ms से कम। officially एक Core Web Vital नहीं है लेकिन यह हर दूसरे metric को cap करता है। CDN पर static-rendered sites आमतौर पर 50 से 150ms hit करते हैं। shared hosting पर WordPress cold cache पर 800ms से 2.5s hit करता है। hosting decision सबसे बड़ी TTFB lever है।

Lab data आपको बताता है कि एक machine ने एक location में एक moment पर controlled conditions के तहत क्या measure किया। Field data आपको बताता है कि real users ने scale पर क्या experienced किया। दोनों अधिकांश sites पर significantly diverge करते हैं, और field data वह है जिसे Google ranking signals के लिए उपयोग करता है। field data को पहले optimize करें, lab data को दूसरा।

Field data कहां पढ़ें

Search Console > Core Web Vitals रिपोर्ट। Raw event-level data के लिए BigQuery पर CrUX dataset। PageSpeed Insights > Field Data सेक्शन (जब URL के लिए पर्याप्त real user data हो)। Calibre, SpeedCurve, और Treo paid users के लिए CrUX के ऊपर enriched dashboards प्रदान करते हैं। RUM tooling (real user monitoring) जैसे Vercel Analytics या Cloudflare Web Analytics अतिरिक्त granularity जोड़ते हैं।

Lab data कहाँ पढ़ें

PageSpeed Insights > Lab Data सेक्शन। Chrome DevTools में Lighthouse। Granular waterfall analysis के लिए WebPageTest। Field metric regression के पीछे की वजह diagnose करने के लिए उपयोगी है, इसे measure करने के लिए नहीं।

मैं जो diagnostic flow चलाता हूँ

Search Console में field metric regression। Affected URL pattern की पहचान करें। तीन locations से WebPageTest के माध्यम से lab tests चलाएँ ताकि reproduce कर सकें। Waterfall को inspect करके offending request खोजें। Patch करें। CrUX field data के update के लिए 28 दिन प्रतीक्षा करें। Fix की पुष्टि करें।

Real LCP numbers जो मैंने field data के 75th percentile पर देखे हैं उन platforms पर जिन पर मैं सबसे ज्यादा ship करता हूँ:

Static-rendered Astro on Netlify या Cloudflare Pages

LCP 0.6 से 1.0 सेकंड आम तौर पर। सभी चार metrics में Lighthouse 100 default outcome है। 30KB से कम initial JavaScript। Content sites के लिए सबसे मुश्किल tier है।

Static-rendered Next.js (App Router with RSC, SSG mode)

LCP 1.0 से 1.5 सेकंड। शुरुआती JavaScript 80 से 150KB, इस बात पर निर्भर करता है कि आप कितने क्लाइंट कंपोनेंट शिप करते हैं। Lighthouse 90+ हासिल करना संभव है लेकिन जानबूझकर ऑप्टिमाइज़ेशन चाहिए।

ISR या SSR Next.js

LCP 1.5 से 2.5 सेकंड, कैश हिट रेट और ऑरिजिन रेस्पांस टाइम पर निर्भर करता है। कोल्ड कैश मिसेज 3 से 5 सेकंड हैं। शानदार तकनीक लेकिन असली कॉस्ट कर्व और असली परफॉर्मेंस वेरिएंस के साथ।

WordPress on Kinsta या WP Engine के साथ Cloudflare

LCP आम तौर पर 1.8 से 2.8 सेकंड। अनुशासन के साथ CWV थ्रेशहोल्ड को क्लीयर करना संभव है। मैं इस स्टैक पर जो साइटें चलाता हूँ, वे ऑप्टिमाइज़ेशन पास के बाद 75वें परसेंटाइल पर लगातार CWV पास करती हैं।

साझा होस्टिंग पर WordPress

LCP 3.5 सेकंड या उससे भी बदतर। किसी भी साइट के लिए इससे बचें जहाँ परफॉर्मेंस ब्रीफ का हिस्सा है।

मोटे तौर पर 70% मार्केटिंग पेजों पर इमेज ही LCP एलिमेंट है। इमेज डिसिप्लिन वह सबसे ज़्यादा लाभकारी परफॉर्मेंस लीवर है जो मैं जानता हूँ।

फॉर्मेट और कंप्रेशन

WebP quality 82 पर गुणवत्ता और फ़ाइल आकार के बीच सही संतुलन बैठता है। AVIF छोटा है लेकिन encoding धीमी है और ब्राउज़र सपोर्ट में सूक्ष्म अंतराल हैं। JPEG और PNG को छोड़ दें, जब तक वह source-of-truth originals न हों। WebP at q=82 आमतौर पर source PNG से 70 से 90% छोटी फ़ाइलें बनाता है, बिना किसी perceptual loss के।

वास्तविक rendered dimensions तक resize करें

एक 4K JPEG जो 1200 pixels चौड़ाई पर render हो, 90% bandwidth बर्बाद है। हमेशा सबसे बड़े आयाम तक resize करें जिस पर इमेज render होगी, साथ ही high-density displays के लिए 2x या 3x version भी। Sharp किसी भी Node.js build pipeline में इसे लगभग पाँच लाइनों के कोड में करता है।

FAL hero pipeline

हम FAL flux-pro/v1.1-ultra और Imagen 4 के ज़रिए auto-blog pipeline से सीधे hero images generate करते हैं। Generated images 1200x675 पर 600KB से 1.5MB के JPEGs हैं। Supabase Storage को raw upload करने का मतलब हर page के साथ ~1MB hero ही ship होता है। Storage upload से पहले sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer() के through जाता है। फ़ाइल आकार 90% कम करता है, बिना किसी perceptual loss के। एक Seahawk site पर 53 hero images में इस pipeline को लागू करने के बाद हमने site-wide 50MB की बचत देखी। Storage upload पर cacheControl: 31536000 भी लगाएँ।

हर img पर explicit width और height

ब्राउज़र image load होने से पहले स्पेस reserve करते हैं, लेकिन केवल अगर width और height HTML में present हों। उनके बिना, images load होने पर layout shifts होते हैं और CLS बढ़ता है। Astro और Next.js Image components यह automatically handle करते हैं; raw img tags को इसे manually करना पड़ता है।

LCP image preload

Above-the-fold hero image को link rel="preload" as="image" के साथ head में preload किया जाना चाहिए। आमतौर पर 100 से 400ms बचाता है। अधिकांश marketing sites पर उपलब्ध single highest-impact one-line change।

JavaScript अधिकांश आधुनिक साइटों पर सबसे बड़ी परफॉर्मेंस की समस्या है। 2026 में मेरा बजट:

कंटेंट साइटों पर शुरुआती JavaScript 100KB से कम

100KB के नीचे, फ्रेमवर्क, साइट और कोई भी एनालिटिक्स या मार्केटिंग पिक्सल मिलाकर मिड-टियर मोबाइल डिवाइस पर तेजी से पार्स और एक्सीक्यूट होते हैं। 100KB से ऊपर, कॉस्ट INP और TTI में दिखाई देती है, अक्सर डेस्कटॉप डेवलपर के लिए अदृश्य रहती है जो तेज लैपटॉप पर टेस्टिंग कर रहा होता है।

उस सब कुछ को defer करें जो above-the-fold नहीं है

एनालिटिक्स, सोशल पिक्सल, चैट विजेट, A/B टेस्टिंग स्क्रिप्ट। इनमें से किसी को भी पहले पेंट को ब्लॉक करने की जरूरत नहीं है। defer एट्रिब्यूट का उपयोग करें या यूजर इंटरेक्शन पर लोड करें। CWV में सुधार अक्सर नाटकीय होता है, एनगेजमेंट का नुकसान आमतौर पर शून्य होता है।

above-the-fold में भारी क्लाइंट कंपोनेंट से बचें

एक hero carousel जिसके लिए React + framer-motion + 30KB सपोर्टिंग कोड की जरूरत है पहले फ्रेम को रेंडर करने के लिए, यह परफॉर्मेंस की समस्या है। पहली स्लाइड को स्टैटिक HTML के रूप में रेंडर करें और carousel को तभी hydrate करें जब यूजर इंटरेक्ट करने वाला हो।

तीसरे पक्ष की स्क्रिप्टों की त्रैमासिक ऑडिट करें

मार्केटिंग स्क्रिप्ट चुप्पी से जमा होती हैं। 2020 में एक एनालिटिक्स टैग वाली साइट 2026 तक आठ स्क्रिप्ट हो गई है अगर किसी ने ऑडिट नहीं किया। Lighthouse या webpagetest के जरिए त्रैमासिक जांच चलाएं, पहचानें कि कौन सी चीजें अभी भी अपनी जगह कमा रही हैं, और कुछ भी हटाएं जो नहीं है।

Critical CSS inlined, बाकी deferred

Above-the-fold को render करने के लिए जरूरी CSS को head में inline किया जाना चाहिए। बाकी asynchronously load हो सकता है। Astro और Next.js अपने CSS scoping के साथ यह automatically handle करते हैं; manual sites को build pipeline में critical-css extraction step की जरूरत होती है।

Fonts को self-host करें और font-display: swap का उपयोग करें

Google Fonts से load किए गए web fonts आमतौर पर 100 से 300ms add करते हैं। Site के same origin से self-hosting DNS lookup को eliminate करता है। font-display: swap fallback text को तुरंत render करता है जबकि web font load हो रहा हो, FOIT (flash of invisible text) को eliminate करता है। Variable fonts जहाँ supported हों, एक single file से multiple weights deliver करते हैं।

Fonts को उन languages के लिए subset करें जिन्हें आप actually serve करते हैं

Latin font subset 30 से 60KB है। Full multi-language file अक्सर 250KB+ होती है। Subsetting अधिकांश build pipelines में एक one-line change है और हर page load पर significant bandwidth बचाता है।

Hosting और edge layer उतना ही मायने रखता है जितना कि अधिकांश teams को credit देते हैं। Non-obvious सलाह:

Origin के सामने हमेशा Cloudflare लगाएँ

चाहे आपका origin Vercel हो, Netlify हो, AWS हो, या managed WordPress host हो, Cloudflare को सामने लगाने से global latency improve होती है, bot traffic को absorb होता है, और caching add होती है जो origin अन्यथा serve करता। Free tier अधिकांश sites के लिए पर्याप्त है; paid tiers observability और security features add करते हैं।

Static rendering सबसे बड़ा performance lever है

CDN edge nodes से serve किया गया pre-rendered HTML globally sub-100ms TTFB hit करता है। कोई origin hop नहीं, कोई database query नहीं, कोई template render नहीं। अगर आपके content को strictly dynamic होने की जरूरत नहीं है, तो इसे statically render करें।

Dynamic surface के लिए edge functions

जब आपको dynamic behaviour की जरूरत होती है (auth, personalisation, A/B), तो Cloudflare Workers या Vercel Edge Functions पर edge functions origin servers की तुलना में user के ज्यादा करीब execute होते हैं। Infrastructure चलाने के operational burden के बिना latency dramatically drop होती है।

Vercel पर scale में ISR billing को देखें

Incremental Static Regeneration एक बेहतरीन technology है जिसकी एक real cost curve है। हमने March 2026 में Deluxe Astrology पर एक multi-million-event ISR billing month को hit किया। Fix एक explicit "two production merges per week" rule था, क्योंकि हर merge लगभग six million ISR write events को 91,000-page scale पर fire करता है। अगर आप किसी बड़ी site पर ISR चला रहे हैं तो इसके लिए plan करें।

किसी भी नई site या template को launch-ready घोषित करने से पहले, मैं इस checklist को चलाता हूँ। यह intentionally छोटी है। लंबी checklists कभी use नहीं होती हैं।

1. Hero image को link rel preload के साथ image के रूप में preload किया जाता है। 2. Above-the-fold images में explicit width और height हैं। 3. WebP format, quality 82, render dimensions को resize किया गया। 4. Critical CSS inlined, बाकी deferred। 5. Web fonts self-hosted with font-display: swap। 6. Initial JavaScript 100KB के अंदर। 7. Analytics और marketing scripts deferred। 8. CSS Grid columns minmax(0, 1fr) use करते हैं not 1fr long content पर overflow को prevent करने के लिए। 9. Static rendering जहाँ content allow करता है। 10. Cloudflare origin के सामने। 11. Field data Search Console के through weekly measured। 12. Build-time SEO linter regressions पर build को fail करता है।

जो sites इन बारह के साथ ship करती हैं उनमें rarely CWV issues होते हैं। जो sites इनमें से तीन या चार को skip करती हैं वे eventually 75th percentile पर fail होती हैं और team को Google के notice करने के बाद इसे fix करने के लिए scramble करना पड़ता है।

हर साइट को Lighthouse 100 हासिल करने की ज़रूरत नहीं है। "कितना परफ़ॉर्मेंस काम काफ़ी है" इस सवाल का ईमानदारी से जवाब:

10,000 से कम मासिक विजिटर वाली साइटें जिनकी सर्च रैंकिंग पर कोई व्यावसायिक निर्भरता नहीं है: 75वें परसेंटाइल पर CWV थ्रेशहोल्ड हासिल करें और रुक जाएँ। आगे की ऑप्टिमाइज़ेशन से घटते फ़ायदे मिलते हैं। समय कंटेंट या प्रोडक्ट पर लगाएँ।

पेड ट्रैफ़िक वाली साइटें जहाँ कन्वर्ज़न रेट मायने रखता है: हर 100ms LCP में आमतौर पर 1 से 4% कन्वर्ज़न खर्च होता है। CWV थ्रेशहोल्ड के बाद की ऑप्टिमाइज़ेशन आमतौर पर बड़े पैमाने पर फ़ायदेमंद होती है। गणित करें, प्राथमिकता तय करें।

साइटें जहाँ Lighthouse स्कोर ब्रैंड ब्रीफ़ का हिस्सा है: Lighthouse 100 हासिल करें और किसी भी रिग्रेशन को बग मानें। ऑप्टिमाइज़ेशन काम जमा होता है क्योंकि टीम रिग्रेशन को शिप नहीं होने देगी।

एडिटोरियल टीमें जो ऑप्टिमाइज़ेशन डिसिप्लिन बनाए नहीं रखेंगी: ऐसा फ़्रेमवर्क चुनें जो डिफ़ॉल्ट रूप से परफ़ॉर्मेंस देता है (Astro, स्टैटिकली-रेंडर्ड Next.js, हेडलेस WordPress मैनेज़्ड होस्टिंग के साथ) और इस पाबंदी को स्वीकार करें। मैनुअल परफ़ॉर्मेंस ट्यूनिंग जो टीम नहीं बनाए रख सकती वह थोड़ा कम ऑप्टिमल डिफ़ॉल्ट से कम मूल्यवान है जो चलती रहती है।

2026 में परफ़ॉर्मेंस एक संरचनात्मक मुद्रा है: फ़्रेमवर्क चुनाव, होस्टिंग चुनाव, इमेज पाइपलाइन डिसिप्लिन, JavaScript बजट, CSS और फ़ॉन्ट डिसिप्लिन, एज कैशिंग, और हर लॉन्च पर लागू CWV चेकलिस्ट। जो साइटें ये जल्दी बनाती हैं उन्हें एक परफ़ॉर्मेंस फ़्लोर मिलता है जो बढ़ता है। जो साइटें इसे बाद में लगाती हैं वो ज़्यादा खर्च करती हैं और कम पाती हैं।

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

अगर आप अपनी साइट के लिए Core Web Vitals ऑडिट चाहते हैं, हम Seahawk Media पर 2,500 USD से शुरू करके ये ऑडिट करते हैं। ऑडिट फ़ील्ड-डेटा विश्लेषण, प्राथमिकता वाला समाधान, और एक टार्गेट मेट्रिक प्रोफ़ाइल देता है जिसे आप समय के साथ ट्रैक कर सकते हैं।