दिन 6: Page Speed और Core Web Vitals
✅ आज आप सीखेंगे
- Core Web Vitals क्या मापते हैं
- Good / needs-improvement / poor सीमाएँ
- Field data बनाम lab data
- PageSpeed Insights और Search Console से मापना
- सबसे आम speed समस्याएँ ठीक करना
🏢 असली दुनिया में
Institute के ज़्यादातर visitors mobile data पर आते हैं। Gallery page पर phone camera से सीधी 12 photos हैं, हर एक 4 MB, और enquiry banner load होने पर Tally page उछलता है। Page पूरा load होने से पहले students चले जाते हैं। आज आप इसे मापकर ठीक करेंगे।
तीन Core Web Vitals
| Metric | क्या मापता है | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP – Largest Contentful Paint | Loading: मुख्य content (बड़ी image या heading) कब दिखता है | ≤ 2.5 s | 2.5 – 4.0 s | > 4.0 s |
| INP – Interaction to Next Paint | Responsiveness: taps और clicks पर page कितनी जल्दी प्रतिक्रिया देता है | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS – Cumulative Layout Shift | Visual stability: layout कितना उछलता है | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
Google इन्हें असली visits के 75th percentile पर आँकता है। Page तभी “pass” होता है जब तीनों Good हों। INP ने March 2024 में पुराने FID metric की जगह ली। Google sites का mobile version index करता है, इसलिए mobile performance सबसे ज़रूरी है।
Page experience कई signals में से एक है। कमज़ोर content वाला तेज़ page, query का कहीं बेहतर जवाब देने वाले धीमे page को नहीं हराएगा – पर मिलते-जुलते pages में तेज़ वाला जीतता है, और तेज़ pages ज़्यादा visitors को convert करते हैं।
मापें: field data बनाम lab data
Field data (असली users)
- Chrome users से (CrUX)
- PageSpeed Insights के ऊपर और Search Console → Core Web Vitals में
- Google यही इस्तेमाल करता है
- पर्याप्त traffic चाहिए
Lab data (एक test)
- Lighthouse simulation
- PageSpeed Insights नीचे का हिस्सा, Chrome DevTools
- Debugging के लिए बढ़िया
- असली users से अलग हो सकता है
| Page | LCP | INP | CLS | परिणाम |
|---|---|---|---|---|
| / (home) | 3.8s सुधार चाहिए | 180ms अच्छा | 0.02 अच्छा | ❌ Fail |
| /courses/tally/ | 2.1s अच्छा | 140ms अच्छा | 0.18 सुधार चाहिए | ❌ Fail |
| /courses/python/ | 1.9s अच्छा | 90ms अच्छा | 0.04 अच्छा | ✅ Pass |
| /gallery/ | 5.6s ख़राब | 620ms ख़राब | 0.31 ख़राब | ❌ Fail |
सिर्फ़ /courses/python/ तीनों में pass है। Home page LCP में, Tally page CLS में, और gallery तीनों में fail है।
आम सुधार
| समस्या | असर | सुधार |
|---|---|---|
| बहुत बड़ी images | LCP | Display size पर resize, compress, WebP/AVIF, hero image preload |
| Hero image को lazy-load करना | LCP | पहली दिखने वाली image कभी lazy-load न करें; fetchpriority="high" |
| धीमा server / caching नहीं | LCP | Caching और compression चालू, CDN, ज़रूरत हो तो hosting बदलें |
| भारी JavaScript, बहुत plugins | INP | बेकार scripts हटाएँ, non-critical JS defer, लंबे tasks तोड़ें |
| width/height बिना images, देर से आते banners और ads | CLS | width/height या aspect-ratio दें, banners के लिए जगह रखें |
| देर से बदलते web fonts | CLS | font-display: swap और मुख्य font preload |
<!-- 1. Preload the main (LCP) image and do NOT lazy-load it -->
<link rel="preload" as="image" href="/images/tally-lab-aligarh.webp">
<img src="/images/tally-lab-aligarh.webp" width="800" height="450"
alt="Students practising TallyPrime in our Aligarh lab" fetchpriority="high">
<!-- 2. Lazy-load images further down the page -->
<img src="/images/certificate.webp" width="600" height="400" alt="Course certificate sample" loading="lazy">
<!-- 3. Load non-critical JavaScript without blocking -->
<script src="/js/gallery.js" defer></script>
<!-- 4. Reserve space for embeds and ads to avoid layout shift -->
<div style="aspect-ratio:16/9"><iframe src="..." loading="lazy" title="Demo class video"></iframe></div>Mobile-friendly checklist
- Viewport meta tag मौजूद; horizontal scrolling नहीं।
- बिना zoom पढ़ने लायक text (लगभग 16px body text)।
- Tap targets (buttons, links) पर्याप्त बड़े और बहुत पास नहीं।
- Mobile पर भी desktop जितना ज़रूरी content – Google mobile version index करता है।
- आते ही content रोकने वाले full-screen pop-ups नहीं।
हल किए उदाहरण
उदाहरण 1: Images से कितनी बचत?
Gallery: 12 photos, हर एक 4,200 KB। 1200 px चौड़ाई पर resize और WebP में बदलने के बाद हर एक लगभग 180 KB।
| Value | |
|---|---|
| हर image की बचत | 4,020 KB (95.7%) |
| 12 images की कुल बचत | 48,240 KB ≈ 47.1 MB |
पहली screen के नीचे की images lazy load करने पर visitor शुरू में सिर्फ़ पहली कुछ images download करता है – LCP बहुत घटता है।
अभ्यास प्रश्न (बिना हल – उत्तर छिपा है)
हर प्रश्न पहले ख़ुद करें – कागज़ पर, text editor में या अपनी site पर – फिर उत्तर खोलकर जाँचें।
🏋️ Practice – ख़ुद करें
Solution देखें
/contact/ – LCP अच्छा, INP सुधार चाहिए, CLS अच्छा; /blog/ccc-exam/ – LCP ख़राब, INP अच्छा, CLS अच्छा; /fees/ – LCP अच्छा, INP अच्छा, CLS सुधार चाहिए। कोई pass नहीं – तीनों metrics Good होने चाहिए।Solution देखें
(a) CLS – ad के लिए जगह रखें (b) INP – भारी JavaScript घटाएँ/defer करें (c) LCP – image compress और preload करें, lazy-load न करें।Solution देखें
उत्तर अलग होंगे। Field data न दिखे तो site पर पर्याप्त real-user data नहीं – lab section देखें। सबसे आम सुझाव: images सही size, बेकार JavaScript कम, render-blocking resources हटाना।🏅 आज के Job Skills
Quick quiz
🧠 Quick Quiz – ख़ुद को जाँचें
Interview corner
💼 Interview Corner
Core Web Vitals समझाइए।
असली visits पर 75th percentile पर मापे जाने वाले तीन user-experience metrics: LCP (loading, good ≤ 2.5 s), INP (responsiveness, good ≤ 200 ms) और CLS (visual stability, good ≤ 0.1)। ये Google के page experience signals का हिस्सा हैं।
छोटी website पर LCP कैसे सुधारेंगे?
LCP element ढूँढ़ें, उसे compress और resize (WebP) करें, fetchpriority high के साथ preload करें, lazy-load न करें, caching/CDN चालू करें और render-blocking CSS/JS घटाएँ।
सारांश
- LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 – pass के लिए तीनों।
- Field data फ़ैसला करता है; lab data debugging में मदद।
- Images सबसे बड़ी, आसान जीत।
- Mobile पहले: Google mobile version index करता है।
Day 7: Google Search Console – performance, indexing और URL inspection।
