व्यवहार में Core Web Vitals को बेहतर बनाना — कैसे मैंने LCP को 3s से घटाकर 1.2s किया

मुख्य सारांश

• LCP (Largest Contentful Paint) एक मुख्य मीट्रिक है, जो Google खोज रैंकिंग को सीधे प्रभावित करता है।

• इमेज ऑप्टिमाइज़ेशन, फ़ॉन्ट लोडिंग रणनीति और कोड स्प्लिटिंग को क्रमिक रूप से लागू करके LCP को 3.0 सेकंड से घटाकर 1.2 सेकंड कर दिया गया।
• इमेज और विज्ञापन क्षेत्रों के लिए स्पष्ट आयाम निर्धारित करके और लेआउट शिफ्ट हटाकर CLS को 0.28 से सुधारकर 0.04 किया गया।
• यह एक वास्तविक प्रोडक्शन Next.js प्रोजेक्ट पर आधारित है — यही सिद्धांत React और Vue प्रोजेक्ट्स पर भी लागू होते हैं।

परिचय — Core Web Vitals क्यों?

जब Google ने 2021 में Page Experience अपडेट जारी किया, तो Core Web Vitals साधारण UX मीट्रिक्स से आगे बढ़कर SEO रैंकिंग फैक्टर बन गए। तब से Google इन संकेतों का महत्व लगातार बढ़ाता रहा है, और 2024 तक INP (Interaction to Next Paint) ने मूल्यांकन मीट्रिक के रूप में FID को पूरी तरह बदल दिया है।

मेरे द्वारा संचालित एक ई-कॉमर्स प्रोजेक्ट छह महीने पहले PageSpeed Insights मोबाइल पर केवल 38 अंक हासिल कर रहा था। LCP 3.0 सेकंड था, CLS 0.28 था, INP 320ms था — तीनों मीट्रिक्स "Needs Improvement" ज़ोन में थे। यह लेख उन आंकड़ों को बेहतर बनाने की पूरी प्रक्रिया दर्ज करता है।

आप तीन Core Web Vitals को जल्दी कैसे समझ सकते हैं?

LCP — पेज की "पहली छाप" वाली गति

LCP उस समय को मापता है, जिसमें viewport में मौजूद सबसे बड़ा कंटेंट एलिमेंट (आम तौर पर hero image या H1 text) render होता है। Good के लिए Google की सीमा 2.5 सेकंड या उससे कम है; 4.0 सेकंड से अधिक Poor माना जाता है।

ई-कॉमर्स साइटों पर hero banner image भारी बहुमत में LCP candidate होती है। अगर यही एक इमेज बहुत धीरे लोड होती है, तो बाकी सभी ऑप्टिमाइज़ेशन बेअसर हो जाते हैं।

CLS — क्या लेआउट "उछलता" है?

CLS (Cumulative Layout Shift) यह मापता है कि पेज लोड होने के दौरान एलिमेंट्स अनपेक्षित रूप से कितने खिसकते हैं। देर से लोड होने वाले ad banners या स्पष्ट dimensions के बिना images CLS को तेजी से बढ़ा देते हैं। 0.1 या उससे कम Good threshold है।

INP — पेज यूज़र इनपुट पर कितनी जल्दी प्रतिक्रिया देता है?

INP सभी interactions — clicks, taps, keyboard input — के response delay को मापता है। इसने मार्च 2024 में FID की जगह ली, और 200ms या उससे कम Good threshold है। भारी JavaScript bundles main thread को block करते हैं और INP को खराब बनाते हैं।

समस्या का निदान — शुरुआती माप

ऑप्टिमाइज़ेशन से पहले मेट्रिक्स को सटीक रूप से रिकॉर्ड करना शुरुआती बिंदु है। इन टूल्स का इसी क्रम में उपयोग किया गया:

1. 1PageSpeed Insights — field data (real user data) और lab data (Lighthouse), दोनों एक साथ प्रदान करता है
2. 2Chrome DevTools > Performance tab — rendering timeline और LCP candidate element की जांच
3. 3WebPageTest — CDN edge servers से real-world measurement, filmstrip के जरिए visual confirmation
4. 4Vercel Analytics / Sentry — real user sessions से एकत्र किए गए Core Web Vitals

डायग्नोसिस ने bottlenecks को तीन क्षेत्रों तक सीमित कर दिया:

• Hero image — 4.2MB JPEG, बिना किसी optimization के सीधे tag के जरिए डाली गई
• Google Fonts — @import के जरिए 3 font families synchronously load हुईं
• Bundle size — 1.8MB main chunk, tree-shaking के बिना कई libraries शामिल

वे तीन तरीके क्या थे जिन्होंने LCP को 3.0s से घटाकर 1.2s कर दिया?

तरीका 1 — Image Optimization और Preload

इसका सबसे बड़ा असर हुआ। hero image handling को पूरी तरह redesign किया गया।

पहले

<img src="/banner.jpg" alt="Main Banner" />

बाद में — Next.js Image Component + WebP Conversion

import Image from 'next/image';

<Image
  src="/banner.webp"
  alt="Main Banner"
  width={1920}
  height={800}
  priority          // LCP target images must always have priority
  quality={80}
  sizes="(max-width: 768px) 100vw, 1920px"
/>

सिर्फ priority prop जोड़ने से Next.js image के लिए अपने आप एक tag inject कर देता है। WebP में convert करने के बाद file size 4.2MB से घटकर 340KB हो गया — लगभग 92% की कमी।

pure HTML/React projects के लिए, में सीधे preload tag जोड़ें:

<link
  rel="preload"
  as="image"
  href="/banner.webp"
  type="image/webp"
/>

इस एक बदलाव ने LCP को 3.0s से घटाकर 1.8s कर दिया।

तरीका 2 — Font Loading Strategy

@import के जरिए Google Fonts load करने से browser CSS parsing रोक देता है और font request करता है। यह wait time LCP को काफी बढ़ा देता है।

पहले

<style>
  @import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
</style>

बाद में — + display=swap + Self-hosting

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

<link
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap"
  rel="stylesheet"
  media="print"
  onload="this.media='all'"
/>

media="print" का उपयोग करके और फिर load होने पर media="all" में switch करने से font CSS rendering को block किए बिना asynchronously load होती है। display=swap web font load होते समय तुरंत fallback font दिखाता है, जिससे text visible रहता है।

अधिकतम प्रदर्शन के लिए, fonts को self-host करने से Google Fonts का round-trip पूरी तरह हट जाता है:

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/fonts/inter-regular.woff2') format('woff2');
}

इस चरण से LCP 1.8s से घटकर 1.4s हो गया।

तरीका 3 — Code Splitting और Bundle Optimization

1.8MB main chunk का मतलब है कि page interactive होने से पहले users को लगभग 2MB JavaScript download और parse करनी पड़ती है।

की गई मुख्य कार्रवाइयां:

1. 1Dynamic imports — भारी libraries केवल जरूरत पड़ने पर load की गईं:

// Before: always loaded
import Chart from 'chart.js';

// After: loaded only when the chart component is actually rendered
const Chart = dynamic(() => import('chart.js'), { ssr: false });

1. 1Tree-shaking audit — import _ from 'lodash' को अलग-अलग function imports से बदला गया:

// Before: loads entire lodash library
import _ from 'lodash';

// After: loads only debounce
import debounce from 'lodash/debounce';

1. 1Third-party script lazy loading — Analytics और chat widget scripts को page interactive होने के बाद load करने के लिए defer किया गया:

Bundle optimization के बाद, main chunk size 1.8MB से घटकर 620KB हो गया, और LCP 1.4s से सुधरकर 1.2s हो गया।

CLS को 0.28 से 0.04 तक कैसे घटाया गया?

CLS के दो सबसे बड़े कारण ads और explicit dimensions के बिना images थे।

Ad Area: पहले से जगह Reserve करें

/* Reserve minimum height so ad slot never causes layout shift */
.ad-container {
  min-height: 90px;  /* banner ad */
  min-width: 728px;
}

Images: हमेशा Width/Height Specify करें

/* Before: no dimensions → causes layout shift during load */
<img src="/product.jpg" alt="Product" />

/* After: explicit dimensions → browser reserves space */
<Image
  src="/product.jpg"
  alt="Product"
  width={400}
  height={300}
/>

Dynamic Content: Placeholders का उपयोग करें

// Show skeleton placeholder while data is loading
{isLoading ? (
  <div className="h-48 bg-gray-200 animate-pulse rounded" />
) : (
  <ProductCard data={data} />
)}

इन तीन बदलावों से CLS 0.28 से घटकर 0.04 हो गया।

परिणाम सारांश

अपनी Site के Core Web Vitals जांचें

अपना current score मापने के लिए इन tools का उपयोग करें:

• PageSpeed Checker — PageSpeed Insights score तुरंत जांचें
• Meta Tag Checker — SEO और OG tag configuration को साथ-साथ verify करें

अक्सर पूछे जाने वाले प्रश्न (FAQ)

Q1. क्या Core Web Vitals में सुधार सीधे search rankings बढ़ाता है?

Core Web Vitals, Google के आधिकारिक ranking factors में से एक हैं। Google ने सार्वजनिक रूप से पुष्टि की है कि ये Page Experience signal हैं। हालांकि, content quality और backlinks जैसे दूसरे factors अभी भी अधिक प्रभाव रखते हैं, इसलिए Core Web Vitals में सुधार को guarantee के बजाय एक जरूरी condition के रूप में देखना चाहिए।

Q2. Core Web Vitals की कौन-सी metric rankings पर सबसे ज्यादा असर डालती है?

LCP users को सबसे स्पष्ट रूप से दिखता है और bounce rates पर इसका सबसे सीधा असर होता है, जो अप्रत्यक्ष रूप से rankings को प्रभावित करता है। CLS भी सीधे UX को प्रभावित करता है, इसलिए दोनों high-priority targets हैं। INP का प्रभाव, एक नई metric होने के कारण, अभी भी स्थापित हो रहा है।

Q3. मैं अपना LCP element कैसे check करूं?

Chrome DevTools खोलें, Performance tab पर जाएं, page load record करें, और timeline में "LCP" देखें। वैकल्पिक रूप से, PageSpeed Insights चलाने पर आपको ठीक-ठीक बताया जाएगा कि कौन-सा element LCP candidate है।

Q4. क्या Google Fonts Core Web Vitals को नुकसान पहुंचाता है?

हां। @import के जरिए Google Fonts load करना rendering को block करता है और LCP खराब होने का एक आम कारण है। को display=swap के साथ इस्तेमाल करना या fonts को self-host करना strongly recommended है।

Q5. Next.js Core Web Vitals में कितनी मदद करता है?

काफी ज्यादा। Next.js built-in features के रूप में automatic image optimization (WebP conversion, lazy loading, size optimization), built-in font optimization (next/font), और route-based code splitting देता है। सिर्फ ये features ही बिना extra configuration के Core Web Vitals में बड़ा सुधार ला सकते हैं।

Q6. Core Web Vitals को कितनी बार check करना चाहिए?

कम से कम महीने में एक बार monitoring करना recommended है। PageSpeed Insights पिछले 28 दिनों में collect किए गए real user data को दिखाता है, इसलिए बदलाव दिखने में समय लगता है। समय के साथ field data trends track करने के लिए Google Search Console का इस्तेमाल one-off measurements से ज्यादा practical है।