Core Web Vitals की व्याख्या: LCP, INP और CLS सरल भाषा में

Core Web Vitals आपकी वेबसाइट का personality test नहीं हैं

Core Web Vitals को अक्सर किसी रहस्यमय scorecard की तरह देखा जाता है। किसी page को लाल number मिलता है, कोई Slack में screenshot पोस्ट करता है, और team JavaScript frameworks पर बहस शुरू कर देती है।

यह खास उपयोगी नहीं है।

Core Web Vitals के बारे में सोचने का बेहतर तरीका सरल है: ये इस बात के तीन measurements हैं कि कोई page वास्तविक device पर वास्तविक व्यक्ति को usable महसूस होता है या नहीं। ये performance, accessibility या quality के हर पहलू को नहीं पकड़ते। लेकिन ये frustration के तीन आम स्रोतों को जरूर पकड़ते हैं:

• मुख्य content दिखने में बहुत देर लगती है।
• जब user कुछ करने की कोशिश करता है तो page धीमी प्रतिक्रिया देता है।
• user के पढ़ते या tap करते समय layout इधर-उधर कूदता है।

यही तीन Core Web Vitals हैं: LCP, INP और CLS।

Google इन्हें अपने page experience signals के हिस्से के रूप में इस्तेमाल करता है, लेकिन SEO वाला पहलू इनकी परवाह करने का सबसे अच्छा कारण नहीं है। बेहतर कारण यह है कि slow, jumpy, unresponsive pages users का समय बर्बाद करते हैं। वे अक्सर कम convert करते हैं, support में अधिक कठिन होते हैं, और समय के साथ खराब ढंग से age करते हैं।

तीनों metrics, एक-एक वाक्य में

Details में जाने से पहले, इसका सरल version यह है:

• LCP, या Largest Contentful Paint, मापता है कि मुख्य visible content को load होने में कितना समय लगता है।
• INP, या Interaction to Next Paint, मापता है कि visit के दौरान page user interactions का कितनी जल्दी जवाब देता है।
• CLS, या Cumulative Layout Shift, मापता है कि page अप्रत्याशित रूप से कितना इधर-उधर हिलता है।

आम thresholds ये हैं:

| Metric | अच्छा | सुधार की जरूरत | खराब | |---|---:|---:|---:| | LCP | 2.5s या उससे तेज | 2.5s–4.0s | 4.0s से अधिक | | INP | 200ms या उससे तेज | 200ms–500ms | 500ms से अधिक | | CLS | 0.1 या कम | 0.1–0.25 | 0.25 से अधिक |

इन numbers का मूल्यांकन सामान्यतः वास्तविक user visits के 75th percentile पर किया जाता है। यह महत्वपूर्ण है। आपका लक्ष्य एक perfect lab run बनाना नहीं है। आपका लक्ष्य अधिकांश users के लिए experience अच्छा बनाना है, जिसमें slower phones और messy networks वाले लोग भी शामिल हैं।

यदि आप किसी automated report को देख रहे हैं और समझ नहीं पा रहे कि कहाँ से शुरू करें, तो diagnosis को panic से अलग करना मदद करता है। हमारे पास how to read a Lighthouse report without panicking पर एक अलग guide है, जो इस workflow को अधिक detail में cover करती है।

LCP: page कब loaded महसूस होता है?

Largest Contentful Paint viewport में सबसे बड़े visible content element के render time को मापता है। व्यवहार में, यह अक्सर इनमें से कोई होता है:

• एक hero image,
• एक बड़ा heading,
• एक featured article image,
• एक product image,
• text का एक बड़ा block।

LCP यह नहीं पूछता कि हर script, tracking pixel और below-the-fold image कब loading पूरी कर चुके। यह पूछता है: जिस मुख्य चीज को देखने के लिए user आया था, वह कब visible हुई?

इसी वजह से LCP पुराने “page load time” की तुलना में अधिक human metric है। कोई page technically देर से loading पूरी कर सकता है, लेकिन अगर मुख्य content जल्दी दिख जाता है तो वह fast महसूस हो सकता है। उल्टा भी सच है: कोई page load event fire कर सकता है जबकि hero area अभी भी blank, blurred या render delay से blocked हो।

खराब LCP के आम कारण

अधिकांश खराब LCP problems कुछ predictable जगहों से आते हैं:

1. Slow server response

यदि HTML document देर से आता है, तो बाकी सब कुछ देर से शुरू होता है।

1. Render-blocking CSS या JavaScript

Browser के पास content है, लेकिन वह अभी उसे paint नहीं कर सकता।

1. Unoptimised hero images

सबसे बड़ा element बहुत बड़ा है, गलत format में है, prioritised नहीं है, या गलती से lazily loaded है।

1. Web fonts text rendering में delay कर रहे हैं

कोई बड़ा heading LCP element हो सकता है, और font loading उसे delay कर सकती है या visually बदल सकती है।

1. Client-side rendering delays

यदि page को meaningful content दिखाने से पहले एक बड़े JavaScript bundle की जरूरत है, तो LCP प्रभावित होता है।

LCP कैसे सुधारें

Actual LCP element से शुरू करें। जब तक आपको पता न हो कि browser क्या measure कर रहा है, random assets optimise न करें।

व्यावहारिक fixes में शामिल हैं:

• HTML जल्दी serve करें: जहाँ उचित हो cache करें, backend work कम करें, slow redirects से बचें।
• LCP image optimise करें: सही dimensions, compression और format इस्तेमाल करें।
• Above-the-fold hero image को lazy-load न करें।
• जब main image सचमुच priority हो, तो fetchpriority="high" सावधानी से इस्तेमाल करें।
• Critical CSS को केवल तभी inline करें जब वह render delay को meaningful रूप से कम करे।
• First meaningful render से पहले जरूरी JavaScript कम करें।
• font-display: swap या कोई अन्य intentional font strategy इस्तेमाल करें।

Images और fonts अक्सर दोषी होते हैं। Images के लिए trade-off सिर्फ “small file good” नहीं है। Format choice, encoding effort और browser support सभी मायने रखते हैं, इसी वजह से हम कब AVIF WebP से बेहतर है और कब नहीं के लिए एक practical decision tree रखते हैं। Type-heavy pages के लिए, web fonts अब भी सबसे आसान performance wins में से हैं, क्योंकि कई sites जितनी font files इस्तेमाल करती हैं उससे अधिक ship करती हैं।

INP: touch करने पर page respond करता है?

Interaction to Next Paint responsiveness को मापता है। अधिक स्पष्ट रूप से, यह user interaction और browser द्वारा उस interaction को process करने के बाद अगले visual update के बीच की delay को देखता है।

Interactions में ये चीजें शामिल हैं:

• button click करना,
• menu tap करना,
• checkbox select करना,
• form field में type करना,
• accordion खोलना।

INP ने 2024 में First Input Delay को Core Web Vital के रूप में replace किया। यह अच्छा बदलाव था। First Input Delay सिर्फ पहले interaction को देखता था। INP व्यापक है: यह page visit के दौरान interactions पर विचार करता है और high-latency interaction को page की responsiveness score के रूप में report करता है।

सरल भाषा में: INP उन pages को पकड़ता है जो loaded दिखते हैं लेकिन stuck महसूस होते हैं।

आपने शायद ऐसा page इस्तेमाल किया होगा। वह ready दिखता है। आप menu tap करते हैं। आधे second तक कुछ नहीं होता। आप फिर tap करते हैं। फिर दो चीजें एक साथ हो जाती हैं। यह INP problem है।

खराब INP के आम कारण

INP आमतौर पर main-thread problem होता है। Browser respond करना चाहता है, लेकिन JavaScript, rendering work या layout calculation रास्ते में है।

Typical causes में शामिल हैं:

• बड़े JavaScript bundles,
• expensive event handlers,
• client-rendered apps पर hydration work,
• main thread के लिए compete करते third-party scripts,
• page load के बाद long-running tasks,
• छोटे interactions से trigger होने वाले complex DOM updates,
• layout thrashing, जहाँ code बार-बार layout values read और write करता है।

Marketing tags, analytics, chat widgets और consent banners सभी योगदान दे सकते हैं। इसका अर्थ “सब कुछ हटा दें” नहीं है। इसका अर्थ है कि page पर हर script की एक cost होती है, और interaction latency वह जगह है जहाँ वह cost अक्सर visible हो जाती है।

INP कैसे सुधारें

INP सुधारना किसी एक magic attribute से कम और main-thread contention कम करने से अधिक जुड़ा है।

Useful approaches में शामिल हैं:

• Long JavaScript tasks को छोटे chunks में बाँटें।
• Non-essential work को तब तक defer करें जब तक page usable न हो जाए।
• Unused JavaScript को केवल minify करने के बजाय remove करें।
• Event handlers को छोटा और predictable रखें।
• छोटे state changes के लिए interface के बड़े हिस्सों को re-render करने से बचें।
• जहाँ संभव हो simple visual states के लिए CSS इस्तेमाल करें।
• Third-party scripts audit करें और उन्हें केवल वहीं load करें जहाँ जरूरत हो।

Interaction design को भी देखें। कोई button जो तुरंत visual feedback देता है, अधिक responsive महसूस हो सकता है, भले ही follow-up work में अधिक समय लगे। यह performance का substitute नहीं है, लेकिन good interface engineering का हिस्सा है। accessible web buttons के लिए हमारी checklist इससे overlap करती है: clear states, proper semantics और predictable behaviour users और browsers दोनों की मदद करते हैं।

CLS: page वहीं रहता है जहाँ user उम्मीद करता है?

Cumulative Layout Shift visible elements की unexpected movement को मापता है। यदि कोई user paragraph पढ़ना शुरू करता है और उसके ऊपर कोई ad, image या banner load होकर text को नीचे धकेल देता है, तो यह CLS में योगदान देता है।

CLS seconds में measure नहीं होता। यह इस बात पर आधारित score है कि कितना content हिला और कितनी दूर हिला। कम बेहतर है।

मुख्य शब्द है unexpected। User action से होने वाले layout changes सामान्यतः उसी तरह count नहीं होते। अगर कोई “show more” tap करता है और content expand होता है, तो यह expected है। अगर तीन seconds बाद top पर newsletter banner दिखाई देता है और सब कुछ नीचे धकेल देता है, तो यह expected नहीं है।

खराब CLS के आम कारण

CLS failures अक्सर साधारण होते हैं:

• width और height attributes के बिना images,
• reserved space के बिना ads या embeds,
• content के ऊपर insert किए गए cookie banners,
• अलग metrics के साथ swap होते web fonts,
• late-loading promotional bars,
• page के top के पास dynamically injected content।

Fix आमतौर पर content आने से पहले space reserve करना होता है। Browser को page का shape जितनी जल्दी संभव हो पता होना चाहिए।

CLS कैसे सुधारें

Visible shifts से शुरू करें। Recording देखें या browser tooling का उपयोग करके पहचानें कि कौन से elements move कर रहे हैं।

फिर boring fixes लागू करें:

• Images में explicit width और height attributes जोड़ें।
• Responsive media containers के लिए CSS aspect-ratio इस्तेमाल करें।
• Ads, embeds और iframes के लिए fixed या minimum space reserve करें।
• Load के बाद existing content के ऊपर banners inject करने से बचें।
• Final font जैसे metrics वाले font fallbacks चुनें।
• top, left, width या height जैसी layout properties बदलने वाले animations से बचें; transforms को prefer करें।

CLS उन कुछ performance metrics में से है जहाँ discipline cleverness से बेहतर है। यदि page में stable boxes हैं, तो वह आमतौर पर अच्छा score करता है।

Field data और lab data दोनों उपयोगी हैं, लेकिन वे अलग questions के जवाब देते हैं

Confusion का एक आम स्रोत यह है कि अलग tools अलग numbers दिखाते हैं। यह सामान्य है।

Field data वास्तविक users से आता है। यह actual devices, networks, locations और browser conditions को reflect करता है। Google’s Chrome User Experience Report field data का एक example है।

Lab data controlled test environment से आता है। Lighthouse परिचित example है। यह repeatable है और debugging के लिए उपयोगी है, लेकिन यह आपके users के lived experience जैसा नहीं है।

Field data का उपयोग यह तय करने के लिए करें कि users को वास्तविक problem है या नहीं। Lab data का उपयोग उस problem को reproduce और debug करने के लिए करें।

यह भी याद रखें कि Core Web Vitals का assessment आमतौर पर per URL या URL group होता है, आपकी brand की किसी single abstract property के रूप में नहीं। आपका home page, blog article, pricing page और checkout बहुत अलग bottlenecks रख सकते हैं।

काम का समझदार क्रम

यदि तीनों metrics खराब हैं, तो temptation हर जगह शुरू करने की होती है। इससे बचें।

एक practical order है:

1. सबसे पहले obvious CLS ठीक करें

Missing image dimensions और unstable banners अक्सर quick wins होते हैं।

1. Important templates के लिए LCP सुधारें

उन pages पर focus करें जो matter करते हैं: product pages, landing pages, articles, sign-up flows।

1. Real interactions के साथ INP investigate करें

वे चीजें click करें जिन्हें users वास्तव में click करते हैं। Menus, filters, forms और checkout controls अक्सर initial load trace से अधिक reveal करते हैं।

1. Third-party scripts audit करें

उन्हें रखें जो अपनी cost justify करते हैं। जो नहीं करते, उन्हें remove या delay करें।

1. Performance budget set करें

Budget के बिना performance improvements decay हो जाते हैं। New scripts, images और design components चुपचाप काम को undo कर देंगे।

Important point: badge के लिए optimise न करें। User journey के लिए optimise करें। Low-traffic page पर marginal score improvement, slightly imperfect लेकिन much faster checkout interaction से कम महत्वपूर्ण हो सकता है।

<!-- tool-cta:start -->

💡 इसे आज़माएँ: चूँकि LCP आमतौर पर छवि से जुड़ी समस्या होती है, पहली आसान जीत के रूप में Image Compressor से अपने हीरो एसेट को छोटा करें।

<!-- tool-cta:end -->

Core Web Vitals आपको क्या नहीं बताते

Core Web Vitals उपयोगी हैं, लेकिन incomplete हैं।

वे आपको यह नहीं बताते कि आपका content अच्छा है या नहीं। वे यह नहीं बताते कि आपकी navigation समझ में आती है या नहीं। वे accessibility की guarantee नहीं देते। वे privacy, security, trust, readability या यह नहीं मापते कि page user के question का answer देता है या नहीं।

वे judgment को भी replace नहीं करते। कोई page Core Web Vitals pass कर सकता है और फिर भी unpleasant हो सकता है। कोई complex application threshold miss कर सकता है और फिर भी अपनी constraints के लिए responsibly engineered हो सकता है।

LCP, INP और CLS को smoke alarms की तरह देखें। जब वे बजें, investigate करें। जब वे शांत हों, building की maintenance जारी रखें।