IT

वेबसाइट स्पीड ऑप्टिमाइज़ेशन 2026 — Core Web Vitals 90+ कैसे हासिल करें

Google Core Web Vitals ऑप्टिमाइज़ेशन के लिए 2026 की पूरी गाइड। इसमें LCP, INP और CLS की माप और सुधार शामिल हैं: इमेज ऑप्टिमाइज़ेशन (WebP/AVIF), फॉन्ट प्रीलोडिंग, JavaScript बंडल स्प्लिटिंग, CDN कॉन्फ़िगरेशन। Next.js के कोड उदाहरणों के साथ Lighthouse 90+ हासिल करने के लिए 30-बिंदु चेकलिस्ट शामिल है।

> **मुख्य सारांश** 2026 में Google Core Web Vitals: LCP (Largest Contentful Paint) < 2.5s, INP (Interaction to Next Paint) < 200ms, CLS (Cumulative Layout Shift) < 0.1. ये तीनों मेट्रिक्स सीधे Google search rankings को प्रभावित करते हैं। सबसे अधिक प्रभाव वाली optimizations: ① Images को WebP/AVIF में बदलें ② Fonts preload करें ③ JavaScript code splitting ④ CDN edge deployment. Next.js users सही default configuration के साथ Lighthouse 90+ तक पहुंच सकते हैं।

Core Web Vitals क्या हैं?

Core Web Vitals Google के तीन मुख्य user experience metrics हैं, जिन्हें 2021 से SEO ranking signals के रूप में शामिल किया गया है।

तीन Core Metrics

| Metric | Full Name | यह क्या मापता है | Good | Needs Work | Poor |

|---|---|---|---|---|---|

| **LCP** | Largest Contentful Paint | सबसे बड़ी image या text render होने का समय | < 2.5s | 2.5–4s | > 4s |

| **INP** | Interaction to Next Paint | User click से visual response तक का समय | < 200ms | 200–500ms | > 500ms |

| **CLS** | Cumulative Layout Shift | Load के दौरान unexpected layout movement | < 0.1 | 0.1–0.25 | > 0.25 |

Note: FID (First Input Delay) को 2024 में INP ने replace कर दिया था।

Core Web Vitals क्यों महत्वपूर्ण हैं

**Direct SEO impact**: Google ranking algorithm में शामिल — समान content होने पर तेज site जीतती है

**Bounce rate**: LCP > 3s होने पर mobile bounce rate 53% बढ़ जाता है (Google research)

**Ad revenue**: AdSense RPM time-on-page से जुड़ा होता है → तेज site = अधिक RPM

**Conversion rate**: 1-second delay = 7% conversion drop (Akamai research)

LCP Optimization

LCP आम तौर पर hero image या सबसे बड़े text block के loading time से तय होता है।

Image Optimization (सबसे अधिक प्रभाव)

**Format comparison:**

| Format | Size reduction | Browser support |

|---|---|---|

| JPEG | Baseline | 100% |

| WebP | 25–35% smaller | 98%+ |

| AVIF | 40–50% smaller | 90%+ (2026) |

```html

<picture>

<source srcset="hero.avif" type="image/avif">

<source srcset="hero.webp" type="image/webp">

<img src="hero.jpg" alt="Hero image" width="1200" height="628" loading="eager">

</picture>

```

**Next.js Image component:**

```typescript

import Image from 'next/image'

// LCP images must have priority prop

<Image

src="/hero.jpg"

alt="Hero image"

width={1200}

height={628}

priority // critical — eliminates LCP delay

quality={85}

/>

```

Resource Preloading

```html

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin>

```

Server Response Time (TTFB)

| Method | Impact | Implementation |

|---|---|---|

| CDN | Global edge caching | Cloudflare, Vercel Edge |

| Cache headers | लौटकर आने वाले visitors के लिए instant | Cache-Control: max-age=31536000 |

| SSG/ISR | Pre-rendered HTML | Next.js generateStaticParams |

INP Optimization

INP किसी भी उपयोगकर्ता इंटरैक्शन (click, tap, keyboard) से लेकर browser द्वारा अगला frame render करने तक का समय मापता है।

Main Thread Blocking कम करें

```javascript

// Bad: heavy sync computation blocks click response

button.addEventListener('click', () => {

const result = heavyComputation(data) // blocks main thread

updateUI(result)

})

// Good: offload to Web Worker

const worker = new Worker('heavy-worker.js')

button.addEventListener('click', () => {

worker.postMessage(data) // runs in separate thread

})

worker.onmessage = (e) => updateUI(e.data)

```

Code Splitting (Next.js)

```typescript

import dynamic from 'next/dynamic'

// Defer components not visible on first load

const HeavyChart = dynamic(() => import('./HeavyChart'), {

loading: () => <div>Loading chart...</div>,

ssr: false

})

```

Tree Shaking

```javascript

// Bad: imports entire lodash (70KB+)

import _ from 'lodash'

// Good: imports only what you need (1KB)

import chunk from 'lodash/chunk'

```

CLS Optimization

CLS तब होता है जब load के दौरान ads, images या dynamic content अपनी जगह बदलते हैं।

Image Dimensions हमेशा Specify करें

```html

<img src="photo.jpg" width="800" height="600" alt="photo">

<img src="photo.jpg" alt="photo">

```

Ad Space Reserve करें

```css

.ad-container {

min-height: 250px; /* pre-reserve ad space */

display: flex;

align-items: center;

justify-content: center;

}

```

Font Loading

```css

@font-face {

font-family: 'MyFont';

src: url('/fonts/myfont.woff2') format('woff2');

font-display: swap; /* show system font immediately, swap when loaded */

}

```

Lighthouse 90+ Checklist (30 items)

**LCP (10 items)**

[ ] LCP element पहचानें (DevTools → Performance tab)

[ ] LCP image में priority या preload जोड़ें

[ ] hero image को WebP/AVIF में convert करें

[ ] automatic optimization के लिए next/image इस्तेमाल करें

[ ] srcset के जरिए responsive images दें

[ ] CDN इस्तेमाल करें (Cloudflare Pages, Vercel Edge)

[ ] सत्यापित करें कि TTFB < 600ms है

[ ] जहां संभव हो SSG/ISR इस्तेमाल करें

[ ] अनावश्यक redirects हटाएं

[ ] सभी third-party scripts defer करें

**INP (10 items)**

[ ] Lighthouse में INP score जांचें

[ ] Long Tasks (50ms+) हटाएं — DevTools Performance tab

[ ] heavy computation को Web Workers में move करें

[ ] JavaScript bundle < 200KB (compressed)

[ ] अनावश्यक polyfills हटाएं

[ ] React में useMemo/useCallback लागू करें

[ ] event handlers को debounce/throttle करें

[ ] JS animations की जगह CSS transitions इस्तेमाल करें

[ ] third-party script tags में async/defer जोड़ें

[ ] LCP element के लिए JS execution order optimize करें

**CLS (10 items)**

[ ] सभी images और videos पर width/height सेट करें

[ ] ad containers के लिए न्यूनतम height आरक्षित रखें

[ ] dynamically injected content को नीचे रखें

[ ] @font-face rules पर font-display: swap लागू करें

[ ] font preload link tags जोड़ें

[ ] केवल transform/opacity animate करें (layout बदलने वाली properties नहीं)

[ ] content space पहले से आरक्षित करने के लिए skeleton loaders इस्तेमाल करें

[ ] सत्यापित करें कि sticky/fixed elements content को धकेलते नहीं हैं

[ ] infinite scroll insertion के दौरान scroll position बनाए रखें

[ ] tab-switching animation की height को overflow: hidden के साथ ठीक करें

मापन टूल्स

| Tool | Purpose | URL |

|---|---|---|

| PageSpeed Insights | वास्तविक user LCP/INP/CLS data | pagespeed.web.dev |

| Lighthouse | Lab-based performance score | Chrome DevTools → Lighthouse |

| WebPageTest | Global location testing | webpagetest.org |

| Chrome DevTools | विस्तृत profiling | F12 → Performance tab |

| Core Web Vitals Report | SEO के लिए CrUX field data | Search Console |

FAQ

**Q1. Core Web Vitals Google rankings को कितना प्रभावित करते हैं?** A. Google CWV को "tiebreaker signal" के रूप में बताता है — जब content quality बराबर हो, तो तेज़ site जीतती है. Mobile Page Experience CWV को ranking component के रूप में इस्तेमाल करता है. सटीक weighting public नहीं है, लेकिन real-world tests लगातार LCP > 4s बनाम < 2s वाली sites के बीच ranking differences दिखाते हैं.

**Q2. क्या Lighthouse 90+ Core Web Vitals पास करने जैसा ही है?** A. नहीं. Lighthouse lab simulation का उपयोग करता है; Core Web Vitals real user data (CrUX / Field Data) का उपयोग करते हैं. Perfect Lighthouse 100 score अच्छा field CWV guarantee नहीं करता. SEO rankings को वास्तव में प्रभावित करने वाले data के लिए Google Search Console में Core Web Vitals report देखें.

**Q3. क्या Next.js अपने आप अच्छी performance देता है?** A. आंशिक रूप से. Next.js image optimization (next/image), font optimization (next/font), code splitting, और SSG/ISR out of the box प्रदान करता है. हालांकि, developers को priority attributes सही ढंग से implement करने, अनावश्यक third-party scripts हटाने, और image dimensions specify करने की जरूरत होती है. सही implementation के साथ, Lighthouse 85–95+ हासिल किया जा सकता है.

**Q4. क्या WebP में convert करने से image quality घटती है?** A. quality=80–90 पर, अंतर human eye को महसूस नहीं होता. समान visual quality पर WebP, JPEG की तुलना में 25–35% छोटे file sizes हासिल करता है. AVIF और भी बेहतर compression देता है. Squoosh, Cloudinary, या next/image जैसे tools conversion को automatically handle करते हैं.

**Q5. मैं कैसे पता करूं कि कौन-सा element CLS पैदा कर रहा है?** A. Chrome DevTools → Performance tab में, recording के बाद "Layout Shift" markers देखें. PageSpeed Insights भी movement पैदा करने वाले specific elements के साथ "Avoid large layout shifts" सूचीबद्ध करता है. आम कारण: unsized images, ads loading होकर content को धकेलना, font swaps (FOUT), dynamically injected content.

**Q6. तीसरे-पक्ष की scripts (GA, Hotjar) performance को कितना नुकसान पहुंचाती हैं?** A. काफी ज्यादा — तीसरे-पक्ष की scripts Lighthouse scores को 10–20 points तक घटा सकती हैं। GA4 async loading के साथ अपेक्षाकृत हल्का है; Hotjar या Intercom जैसे भारी tools INP पर बुरा असर डाल सकते हैं। इन scripts को main page interactive होने के बाद तक defer करने के लिए next/script को strategy="afterInteractive" या "lazyOnload" के साथ इस्तेमाल करें।

**Q7. Mobile LCP हमेशा desktop से धीमा होता है — मैं इसे कैसे सुधारूं?** A. Mobile devices में networks और CPUs धीमे होते हैं, इसलिए mobile LCP स्वाभाविक रूप से ज्यादा कठिन होता है। Fixes: ① Mobile के लिए srcset के जरिए छोटा hero image दें ② Mobile पर non-essential images छिपाएं ③ Critical CSS inline करें ④ HTML को CDN edge पर cache करें। Target: mobile पर भी LCP < 2.5s।