Core Web Vitals का इतिहास

 (addyosmani.com)
14 पॉइंट द्वारा GN⁺ 2025-10-10 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • वेबसाइट performance को मापने वाले Core Web Vitals की शुरुआत 2014 से Google की कई टीमों के सहयोग से AMP प्रोजेक्ट की सीमाओं को पार करने और सभी वेबसाइटों पर लागू किए जा सकने वाले ओपन स्टैंडर्ड performance metrics को परिभाषित करने के प्रयास से हुई
  • मई 2020 में तीन मुख्य metrics (loading speed के लिए LCP, interaction responsiveness के लिए FID, visual stability के लिए CLS) आधिकारिक रूप से घोषित किए गए, और इन्हें वास्तविक user experience को दर्शाने वाले field-measurable metrics के रूप में डिज़ाइन किया गया
  • 2021 में Google Search के Page Experience update के जरिए इन्हें search ranking factor के रूप में पेश किया गया, और Top Stories से AMP की अनिवार्यता हटाकर ओपन वेब के लिए प्रतिस्पर्धी माहौल बनाया गया
  • Chrome browser optimization, WordPress जैसे प्रमुख CMS में सुधार, और JavaScript framework सहयोग के जरिए 2023 तक users के इंतज़ार का समय कुल 10,000 साल से अधिक बचाया गया, और 2024 में यह 30,000 साल की बचत तक पहुंचा
  • 2024 में FID को INP से replace करना और SPA के लिए Soft Navigation API लाना जैसे बदलावों के साथ यह लगातार विकसित हो रहा है, और user-centric तेज़ व स्थिर वेब ecosystem बनाने में योगदान दे रहा है

पृष्ठभूमि और प्रेरणा: AMP से ओपन वेब metrics तक

  • Google कई वर्षों से speed और user experience को वेब के मुख्य सिद्धांतों के रूप में जोर देता रहा, लेकिन इसके बावजूद कई साइटें अब भी धीमा अनुभव देती थीं
  • 2010 में Google Search ने site speed को search ranking signal के रूप में इस्तेमाल करना शुरू किया, जो performance को SEO में शामिल करने की शुरुआती कोशिश थी
  • 2015 के आसपास AMP(Accelerated Mobile Pages) प्रोजेक्ट लाया गया, जिसने तेज़ loading के लिए optimized pages दिए, लेकिन Google cache से परोसे जाने वाले बंद environment के कारण openness और flexibility की समस्या पैदा हुई
  • 2018 के Speed Update के जरिए mobile search ranking में page speed को शामिल किया गया, और Google Ads ने भी mobile landing page speed score पेश किया, जिससे यह रेखांकित हुआ कि तेज़ अनुभव बेहतर conversion rate लाता है
  • AMP-केंद्रित approach से आगे बढ़ने के लिए Chrome और Search टीमों ने मिलकर ऐसे ओपन वेब performance metrics पर काम शुरू किया जो किसी खास framework के बिना सभी pages पर लागू हो सकें
    • लाखों pages का विश्लेषण करके तेज़ और user-friendly web pages के public standard को परिभाषित किया गया
    • लक्ष्य ऐसे field-measurable metrics तय करना था जो वास्तविक user experience को दर्शा सकें
    • ऐसे metrics खोजने की कोशिश की गई जिनका user engagement जैसे outcomes से संबंध हो

Core Web Vitals की परिभाषा: user experience के तीन स्तंभ

  • मई 2020 में Google ने Web Vitals initiative की आधिकारिक घोषणा की और Core Web Vitals पेश किए, जिनका फोकस था “सभी web pages पर लागू होने वाले user experience के मुख्य पहलू”

  • शुरुआती Core Web Vitals तीन मुख्य metrics से बने थे

    • Largest Contentful Paint(LCP): यह loading speed metric है जो उस समय को मापता है जब मुख्य content render होता है; यह First Contentful Paint या onload से आगे बढ़कर उस क्षण पर ध्यान देता है जब user वास्तव में meaningful content देखता है
    • First Input Delay(FID): यह interaction responsiveness metric है जो user के पहले interaction और browser response के बीच की देरी को मापता है; इससे पता चलता है कि page तुरंत respond करता है या भारी scripts के कारण delay होता है
    • Cumulative Layout Shift(CLS): यह visual stability metric है जो loading के दौरान page layout के खिसकने की मात्रा मापता है; unexpected layout shifts को जोड़कर देखा जाता है, और कम CLS का मतलब अधिक स्थिर और आरामदायक अनुभव है

  • metrics का चयन व्यापक research और experiments पर आधारित था

    • Amar Sagoo, Annie Sullivan, Vivek Sekhar आदि ने human-computer interaction research के जरिए objective performance numbers और user perception के बीच संबंध पाया
    • loading time के लिए 2~3 सेकंड के भीतर, input response के लिए 100ms के भीतर, और layout shift को न्यूनतम रखना आदर्श माना गया
    • वास्तविक user data का विश्लेषण कर व्यावहारिक threshold targets तय किए गए: LCP 2.5 सेकंड से कम, FID 100ms से कम, CLS 0.1 से कम (75वें percentile के आधार पर)
    • इन thresholds को पूरा करने वाले pages पर users के page छोड़ने की संभावना 24% कम थी

  • Google ने इन metrics को standardized और open बनाने की कोशिश की

    • WICG और web performance standards groups के जरिए web specification drafts प्रकाशित किए गए
    • Chrome और अन्य browsers में इन्हें PerformanceObserver API के जरिए मापा जा सके, ऐसा implementation किया गया
    • मई 2020 में developers के लिए open source web-vitals JavaScript library जारी की गई, जिसे साइट में जोड़कर वास्तविक users का LCP, FID, CLS मापा जा सकता था
    • Addy Osmani ने real time में metrics दिखाने वाला Core Web Vitals extension विकसित किया
    • यह पूरे ecosystem में इन्हें सुलभ और उपयोगी बनाने के व्यापक प्रयास को दर्शाता है

Page Experience: Google Search ranking में Core Web Vitals

  • Google Search टीम ने Core Web Vitals को Page Experience update के हिस्से के रूप में तेज़ी से अपनाया

  • 28 मई 2020 को Google Search Central ने घोषणा की कि इन metrics को ranking algorithm में शामिल किया जाएगा

    • जब content relevance में समान दो pages हों, तब बेहतर user experience देने वाले page को ऊपर rank किया जाएगा
    • Page Experience signals में Core Web Vitals के साथ मौजूदा UX-related signals (mobile-friendliness, HTTPS security, intrusive interstitials से बचाव) को जोड़ा गया
    • बेहतरीन content अब भी सबसे महत्वपूर्ण है, और सिर्फ speed के कारण कोई तेज़ site अधिक relevant site को पीछे नहीं छोड़ेगी
    • tie या बहुत कम अंतर की स्थिति में अच्छे Web Vitals निर्णायक factor बन सकते हैं

  • सबसे उल्लेखनीय घोषणा थी Top Stories carousel से AMP requirement हटाना

    • पहले mobile पर Google News/Top Stories में AMP आवश्यक था, लेकिन Page Experience update के बाद non-AMP pages भी Core Web Vitals और अन्य मानदंड पूरे करने पर शामिल हो सकते थे
    • “AMP अब mobile Top Stories के लिए अनिवार्य नहीं है, और यह अच्छे page experience वाले सभी pages के लिए खुला है”
    • यह दिखाता है कि Google को भरोसा था कि ओपन वेब AMP framework में सीमित हुए बिना भी बेहतर हो सकता है

  • Google ने ecosystem को पर्याप्त advance notice दिया

    • यह मानते हुए कि 2020 COVID-19 pandemic के कारण कठिन वर्ष था, उसने घोषणा की कि ranking changes 2021 तक लागू नहीं होंगे, और कम से कम 6 महीने पहले चेतावनी देने का वादा किया
    • नवंबर 2020 update में बताया गया कि Page Experience ranking changes मई 2021 से शुरू होंगे
    • अंततः Page Experience update का rollout जून 2021 के मध्य में शुरू हुआ और अगस्त के अंत तक पूरी तरह लागू हो गया (mobile search)
    • desktop search के लिए ऐसा ही update फरवरी-मार्च 2022 में लागू किया गया

  • update लागू होने के बाद Google का ranking algorithm Core Web Vitals को सैकड़ों signals में से एक के रूप में इस्तेमाल करने लगा

    • जिन pages ने तीनों CWV metrics में “good” thresholds पूरे किए, उन्हें अच्छा page experience वाला माना गया
    • Google ने Google Search Console में Page Experience report बनाई, जिससे site owners Chrome UX Report data का उपयोग करके threshold पार करने वाले pages का अनुपात देख सकें
    • इससे webmasters और SEO experts को सीधे feedback मिला कि page experience signals के नजरिए से उनकी site कैसी perform कर रही है

  • Google ने search results में अच्छे page experience वाले pages के लिए badge display पर विचार किया, लेकिन कोई स्थायी badge icon नहीं जोड़ा गया

    • इनाम मुख्य रूप से स्पष्ट label के बजाय ranking boost के रूप में दिया गया
    • कुछ समय तक Google ने Search Console और search result experiments में अस्थायी “Page Experience” indicator दिखाया
    • मुख्य बात यह है कि Google performance और UX को सार्वजनिक रूप से incentivize कर रहा है, और अच्छे Core Web Vitals हासिल करने से न सिर्फ users संतुष्ट होते हैं बल्कि search में page visibility भी बेहतर हो सकती है

टूल्स और डेटा: Chrome UX Report और performance measurement

  • Google ने Web Vitals के लिए tools और data में बड़े पैमाने पर निवेश किया

  • Chrome UX Report(CrUX) इस प्रयास का केंद्र था

    • यह 2017 से मौजूद वास्तविक user experience metrics का सार्वजनिक dataset है, जो लाखों Chrome users से लाखों sites के anonymized performance data को एकत्र करता है
    • Core Web Vitals लॉन्च होने पर CrUX ने dataset के सभी origin URLs के लिए तुरंत LCP, FID, CLS की reporting शुरू की
    • कोई भी field performance data को query कर सकता था
    • BigQuery के जरिए access देने के बाद CrUX API और CrUX Dashboard लॉन्च किए गए, जिससे developers और SEO experts आसानी से देख सकें कि उनकी site (या competitors) field में CWV metrics पर कैसा प्रदर्शन कर रही है
    • CrUX History API की शुरुआत से इन metrics का time-series data उपलब्ध हुआ, जिससे कई महीनों की प्रगति को track करना संभव हुआ

  • developer tools के मोर्चे पर भी तेज़ी से integration हुआ

    • 2020 के अंत तक Google के अधिकांश performance tools को Core Web Vitals को highlight करने के लिए update कर दिया गया
    • Lighthouse (Chrome DevTools और PageSpeed Insights में इस्तेमाल होने वाला open-source audit tool) ने CWV-संबंधित diagnostics और scoring को integrate किया
      • इसने Largest Contentful Paint was X seconds (goal <2.5s) जैसी audits जोड़ीं और सुधार के सुझाव दिए
    • Chrome DevTools में Core Web Vitals panel और timeline markers जोड़े गए, ताकि page load के दौरान LCP element या layout shifts को देखा जा सके
    • PageSpeed Insights(PSI) को CWV पर फोकस करने के लिए पूरी तरह redesign किया गया
      • CrUX से लिए गए LCP, FID (बाद में INP), CLS के field data को सबसे ऊपर प्रमुखता से दिखाया गया
    • Google Search Console ने dedicated Core Web Vitals report दी, जो pages को हर metric के लिए Good, Needs Improvement, Poor buckets में group करती थी, ताकि site owners समस्या वाले क्षेत्रों को ठीक-ठीक पहचान सकें
    • इस tooling work का नेतृत्व Elizabeth Sweeny, Paul Irish, Addy Osmani आदि ने किया

  • web development community ने भी third-party tools के जरिए इसका समर्थन किया

    • Real User Monitoring(RUM) service providers ने Core Web Vitals को जल्दी integrate कर लिया
    • Akamai के mPulse, New Relic के Browser agent, Dynatrace, Datadog, SpeedCurve आदि ने LCP, FID, CLS को first-class metrics के रूप में तुरंत support दिया
    • Cloudflare ने भी Browser Insights service शुरू की, जो script insert करके Web Vitals collect कर सकती थी
    • web-vitals JS library की मौजूदगी से सभी analytics tools के लिए इन metrics को collect करना आसान हो गया
    • 2021 तक Core Web Vitals web performance monitoring tools के dashboards में आम हो चुका था
    • इस व्यापक उपलब्धता ने जागरूकता बढ़ाई और developers को performance सुधार आगे बढ़ाने के लिए data दिया

  • Chrome User Experience Report data पूरे web की प्रगति track करने के लिए भी ज़रूरी था

    • 2021 और 2022 के दौरान good CWV वाले traffic का अनुपात लगातार बढ़ा
    • इसकी रिपोर्टिंग अक्सर HTTP Archive के वार्षिक Web Almanac या Google के अपने blog updates में होती थी
    • मापे जा सकने वाले और सार्वजनिक रूप से दिखने वाले metrics ने एक तरह की सकारात्मक प्रतिस्पर्धा पैदा की
    • site owners और platform providers ने Core Web Vitals पर गर्व करना और उन्हें बेहतर बनाने की कोशिश शुरू की

प्रभाव और सुधार: web को और तेज़ और स्थिर बनाना

Chrome browser optimization

  • Core Web Vitals स्थापित होने के बाद web ecosystem भर में इन metrics को बेहतर बनाने के लिए बड़े पैमाने पर बहुआयामी प्रयास शुरू हुए

  • Google Chrome engineering team ने browser की गहराई से समीक्षा की, ताकि Chrome के web pages load और render करने के तरीके को optimize किया जा सके

    • Chrome के विशाल user base को देखते हुए browser-level के छोटे सुधार भी पूरे web को लाभ दे सकते थे
    • इसमें 2020~2023 के बीच Chrome में जारी किए गए प्रमुख optimizations शामिल थे

  • LCP के लिए content prioritization

    • Chrome को इस तरह बदला गया कि वह महत्वपूर्ण content loading को प्राथमिकता दे
    • HTML की शुरुआती कुछ images (जिनमें अक्सर LCP image शामिल होती है) की पहचान कर उन्हें ऊँची network priority दी गई
    • पहली 5 images को इस तरह priority देने से कुछ pages पर LCP 3.1 सेकंड से घटकर 2.5 सेकंड हो गया
    • fetchpriority attribute (Priority Hints mechanism) जैसे नए web standards लाए गए, ताकि developers images या iframes को LCP के लिए high priority के रूप में mark कर सकें

  • Back/Forward Cache(BFCache)

    • तकनीकी जटिलता के कारण Chrome ऐतिहासिक रूप से pages को पूरी तरह BFCache नहीं कर पाता था, लेकिन हाल के वर्षों में उसने कई pages के लिए BFCache सक्षम किया
    • 2023 तक desktop और Android दोनों पर उल्लेखनीय BFCache hit rate वृद्धि हासिल की गई
    • page पर back जाने वाले users उसे तुरंत देख सकते थे (LCP शून्य, input delay शून्य, क्योंकि page unload नहीं हुआ था)
    • Amazon जैसे बड़े platforms ने Chrome के BFCache से लाभ उठाया, और Chrome के सुधारों (version M112) के बाद back/forward cache उपयोग में 22.7%p वृद्धि रिपोर्ट की

  • Prerendering(NoState Prefetch/Prerender2)

    • Chrome ने एक नया prerenderer (Prerender2) जारी किया, जो browser को background में page को पूरी तरह load और render करने देता है और फिर user के navigate करते ही उसे तुरंत swap कर सकता है
    • शुरुआत में इसका उपयोग Google Search (top results prerendering) और typed URL prediction में किया गया, जिससे LCP को नाटकीय रूप से कम किया जा सका
    • Chrome ने रिपोर्ट किया कि omnibox search prerendering उस navigation पर 500~700ms (लगभग 15~25%) median LCP improvement देती है
    • Chrome इसे सावधानी से roll out कर रहा है (गलत predictions या privacy issues से बचने के लिए)

  • Network और scheduling optimization

    • Chrome team ने input responsiveness में आने वाली कई छोटी delays की पहचान की और उन्हें दूर किया
    • pointer down पर preconnect फीचर जोड़ा गया (जब tap/click शुरू होता है, release से पहले), जिससे link navigation के लिए connection setup में कुछ milliseconds की बचत हुई
    • इससे cross-origin navigations में औसतन लगभग 6~10ms तेज़ LCP मिला
    • कई tabs खुले होने पर browser के main thread के काम संभालने के तरीके को सुधारा गया, ताकि contention कम हो
    • task scheduling adjustments और background tabs के लिए Windows 11 के EcoQOS जैसे mechanisms के उपयोग से Chrome ने भारी load वाले scenarios में INP लगभग 5% और LCP लगभग 2% बेहतर किया

  • Rendering और JavaScript engine improvements

    • Chrome के RenderingNG architecture revamp (लगभग 2021 में पूरा) ने rendering को अधिक कुशल बना दिया
    • image loading priority upgrade (ताकि LCP images कम महत्वपूर्ण दूसरे कामों के पीछे block न हों) और V8 में अधिक smart garbage collection timing (idle time के दौरान चलना) ने अधिक smooth experience सुनिश्चित किया
    • Chrome developers ने पाया कि multi-process browser में cookies तक access करने का तरीका jank पैदा करता है
      • हर document.cookie call को अलग process से synchronously fetch करना पड़ता था
      • cookies के लिए shared-memory versioning लाकर Chrome ने cookie access को optimize किया और कई अनावश्यक process hops हटा दिए
      • इससे उन sites पर input delay कम हुआ जो हर interaction पर cookie reads को spam करती थीं

  • इन सभी Chrome optimizations ने मापने योग्य फर्क पैदा किया

    • 2023 के अंत तक Google ने रिपोर्ट किया कि Chrome में औसत page load, Core Web Vitals के अस्तित्व में आने से पहले की तुलना में 166ms तेज़ है
    • पूरे web पर इसका बहुत बड़ा प्रभाव पड़ा: बचाए गए समय को जोड़ने पर, Chrome टीम ने गणना की कि केवल 2023 में speed improvements की वजह से users ने page loading के इंतज़ार में कुल 10,000 साल से अधिक, और pages के input का जवाब देने के इंतज़ार में अतिरिक्त 1,200 साल से अधिक बचाए
    • CWV "अच्छा" मानदंड पूरा करने वाले traffic का अनुपात भी काफ़ी बढ़ा
    • शुरुआती घोषणा के समय लगभग 1/3 page loads ही CWV मानकों के हिसाब से अच्छे थे, लेकिन 2023 तक Chrome के desktop page visits में लगभग 68% और mobile में लगभग 64% ने तीनों CWV thresholds पूरे कर लिए

व्यापक web ecosystem में सुधार

  • सुधार सिर्फ Google की तरफ़ से नहीं आए; व्यापक web developer community, frameworks, और platform vendors भी Core Web Vitals द्वारा पहचानी गई performance समस्याओं को हल करने के लिए आगे आए

  • Image optimization और lazy loading

    • यह समझते हुए कि images अक्सर सबसे बड़ा content होती हैं और LCP की आम वजह भी, web frameworks और CMS ने ज़्यादा smart defaults लागू किए
    • offscreen images के लिए native HTML loading="lazy" को standardize किया गया (Chrome और Yoav Weiss, Addy Osmani जैसे web standards contributors की मदद से) और WordPress सहित अन्य platforms ने इसे अपनाया, जिससे अनावश्यक image loading में भारी कमी आई
    • WordPress ने 2020 में default रूप से images के लिए lazy loading सक्षम करने के बाद इसे बेहतर किया ताकि सबसे पहली banner image को lazy load न किया जाए और LCP में देरी न हो
    • नया &lt;img fetchpriority="high"&gt; attribute frameworks द्वारा तेज़ी से अपनाया गया ताकि main image को तेज़ loading के लिए प्राथमिकता दी जा सके

  • WordPress Performance Team

    • WordPress लगभग 40% websites को चलाता है, इसलिए उसकी performance का असर बहुत बड़ा है
    • शुरुआत में WordPress sites CWV scores में पीछे थीं, और 2021 की एक report ने दिखाया कि WordPress sites का pass rate कुछ अन्य ecosystems की तुलना में कम था, जिससे चेतावनी की घंटी बजी
    • community ने जवाब में WordPress core की speed को व्यवस्थित रूप से सुधारने के लिए एक dedicated Core Performance Team बनाई, जिसमें Google और अन्य कंपनियों के contributors शामिल थे
    • हाल की releases में इस काम के नतीजे दिखे
      • WordPress 6.3 (2023) में theme rendering और asset loading के लिए कई optimizations शामिल थे, और LCP metric के हिसाब से WordPress 6.2 की तुलना में core themes ने block themes के लिए 27% तेज़ और classic themes के लिए 18% तेज़ loading दी
      • यानी सिर्फ WordPress upgrade करने भर से ही लाखों sites तेज़ हो गईं
    • WordPress team ने image processing को optimize किया, कुछ महंगे operations के लिए caching जोड़ी, और performance को नए features के बराबर प्राथमिकता दी
    • नतीजतन, अच्छे CWV scores वाली WordPress sites का अनुपात तेज़ी से बढ़ा (कुछ data दिखाते हैं कि 2020 से 2022 के बीच सभी CWV पूरे करने वाली WP sites का अनुपात 4 गुना से अधिक बढ़ा)

  • Wix और website builders

    • Wix, Squarespace, Duda जैसे अन्य hosted website platforms ने भी Core Web Vitals को performance सुधारने के अवसर के रूप में अपनाया
    • Wix ने caching, तेज़ servers, और बेहतर client-side code जैसे बड़े infrastructure बदलाव किए और अच्छे CWV scores पाने वाली Wix sites का अनुपात कई गुना बढ़ाया
    • case study में Wix ने रिपोर्ट किया कि "अच्छे" CWV वाली sites का अनुपात लगभग एक साल में 4% से बढ़ाकर 33% से अधिक कर दिया गया
    • इससे साबित हुआ कि platform स्तर पर performance-केंद्रित cultural shift बहुत बड़ी संख्या में users को फ़ायदा पहुँचा सकता है
    • Duda जैसे अन्य builders भी अक्सर यह प्रचार करते हैं कि उनके अधिकांश customer sites अच्छे CWV तक पहुँचते हैं, क्योंकि उन platforms ने best practices को default रूप में शामिल किया है (responsive images, CDN delivery, efficient templates आदि)
    • इस competitive pressure की वजह से individual site owners performance experts न होने पर भी उनके इस्तेमाल किए गए platforms अंदरूनी रूप से सुधार आगे बढ़ाते हैं

  • JavaScript frameworks (Chrome Aurora)

    • Chrome Aurora team 2020 के मध्य में Chrome के भीतर एक special task force के रूप में शुरू हुई, ताकि लोकप्रिय JavaScript frameworks के साथ काम किया जा सके
    • Aurora members (Addy Osmani, Kara Erickson, Houssein Djirdeh आदि) ने React/Next.js, Angular, Nuxt, Gatsby जैसे frameworks के authors के साथ क़रीबी सहयोग किया ताकि साझा bottlenecks की पहचान कर solutions दिए जा सकें
    • इस collaboration से निम्नलिखित सुविधाएँ आईं
      • Next.js का next/script component (third-party scripts को main thread के बाहर ज़्यादा efficient तरीके से load करना)
      • Angular का built-in NgOptimizedImage directive (images को अपने आप lazy load करना और सही size व priority सेट करना)
      • Nuxt का Google Fonts optimization module
    • इसका प्रभाव काफ़ी बड़ा था: 2022 में इन frameworks से बनी sites के median Core Web Vitals scores में साफ़ सुधार दिखा
      • Next.js sites का CWV pass rate 20.4% से 27.3% हुआ
      • Angular 7.6% से 13.2% हुआ
      • Nuxt 15.8% से 20.2% तक सुधरा
    • individual success stories भी काफ़ी थीं
      • e-commerce site Land's End ने Angular की image optimization अपनाने के बाद mobile पर LCP में 40% सुधार किया (lab test)
      • CareerKarma ने Next.js की बेहतर script loading का उपयोग करके LCP में 24% कमी हासिल की

  • वास्तविक business metrics

    • अंततः बेहतर Core Web Vitals का मतलब सिर्फ Google को संतुष्ट करना नहीं, बल्कि वास्तविक user satisfaction और business results से संबंध भी है
    • कई कंपनियों ने case studies साझा कीं जो CWV improvements को user engagement से जोड़ती हैं
      • news site Economic Times ने script processing को optimize करके INP सुधारा और pageviews में 42% वृद्धि, bounce rate में 49% कमी हासिल की
      • travel booking site RedBus ने INP सुधारा और conversion rate में 7% वृद्धि देखी
      • भारत के online marketplace Meesho ने LCP को 6.9 seconds से घटाकर 2.5 seconds किया, जिससे bounce rate में लगभग 17% कमी और conversion rate में 3% वृद्धि मिली
    • ये उदाहरण इस बात को मज़बूत करते हैं कि performance सिर्फ एक technical metric नहीं है; यह users के ज़्यादा देर तक रुकने, ज़्यादा पढ़ने और ज़्यादा ख़रीदने में बदलती है
    • ऐसी success stories developers और product teams को Web Vitals को प्राथमिकता देने के लिए और प्रेरित करती हैं

पूरे ecosystem में सुधार के परिणाम

  • browser teams, framework authors, CMS developers, और असंख्य individual web developers के संयुक्त प्रयासों ने web की स्थिति को नाटकीय रूप से बेहतर बनाया
  • स्पष्ट और actionable metrics स्थापित करके, Core Web Vitals ने एक साझा लक्ष्य बनाया जिसका सभी अनुसरण कर सकते थे
  • महत्वपूर्ण बात यह है कि यह उपलब्धि ecosystem को proprietary technology में बंद किए बिना, open standards और data का उपयोग करके हासिल की गई
  • 2023 तक लगभग 40% websites (और अच्छी तरह maintain की गई commercial sites का इससे कहीं अधिक अनुपात) अब सभी Core Web Vitals thresholds पास कर रही थीं, जबकि 2020 की शुरुआत में ऐसा करने वाली sites बहुत कम थीं
  • जो sites पूरी तरह pass नहीं कर पाईं, वे भी आम तौर पर पहले की तुलना में तेज़ और ज़्यादा smooth हो गईं
  • performance awareness की संस्कृति फैली: developers अब बढ़-चढ़कर CWV metrics की monitoring कर रहे हैं (survey के अनुसार लगभग 51% developers Web Vitals को सक्रिय रूप से track और optimize करते हैं)
  • Google ने यह भी कहा कि इन speed improvements को आगे बढ़ाने के बावजूद web platform के प्रति developer satisfaction ऊँचा बना रहा
    • इससे संकेत मिलता है कि guidelines developers को निराशा में नहीं धकेल रही थीं, बल्कि हासिल करने योग्य थीं
    • यह संतुलन महत्वपूर्ण था; अगर CWV goals असंभव होते या tools अपर्याप्त होते, तो developers विरोध कर सकते थे, लेकिन इसके बजाय community web को बेहतर बनाने के लिए एकजुट हुई

metrics का विकास: INP, Soft Navigation आदि

  • Google ने शुरुआत से ही माना था कि Core Web Vitals समय के साथ विकसित होंगे
  • 2020 के तीन metrics का सेट न तो स्थिर रहने के लिए था और न ही उसे पूर्ण माना गया था
  • user experience के दूसरे पहलू, जैसे स्मूद scrolling या पेज के बाद के हिस्से में लंबे tasks, शुरुआती चरण में शामिल नहीं किए गए थे
  • Chrome Web Platform team नए metrics और मौजूदा metrics में सुधार पर लगातार रिसर्च करती रही

Interaction to Next Paint(INP)

  • मूल CWV में एक साफ कमी थी: पहले क्लिक से आगे की interactivity
  • FID सिर्फ पहले input delay को मापता था, जो first impression के लिए महत्वपूर्ण है, लेकिन बाद में पेज कई user interactions के दौरान unresponsive हो सकता है
  • इसे हल करने के लिए Annie Sullivan और Michal Mocny जैसे Googlers ने INP प्रस्तावित किया
    • पेज पर सभी (या कम से कम बहुत से) user interactions को देखकर एक तरह का worst-case, या 98th percentile, delay रिपोर्ट करना
    • "जब उपयोगकर्ता किसी भी समय पेज के साथ interact करता है, तो response में अगला frame paint होने तक कितना समय लगता है?" यह सवाल पूछते हुए event processing और rendering latency को capture करना
  • INP को 2022 में experimental field metric के रूप में rollout किया गया और CrUX में collect किया गया
  • 2023 की शुरुआत तक Google ने पाया कि INP, FID की तुलना में कुल responsiveness issues को बेहतर predict करता है
  • इसलिए घोषणा की गई कि मार्च 2024 में INP, FID की जगह Core Web Vital बनेगा
    • इस बदलाव की जानकारी developers को काफी पहले दे दी गई थी
    • Lighthouse और PageSpeed Insights जैसे tools ने INP दिखाना शुरू किया, साथ में "coming soon as a CWV" का संकेत भी
    • Web.dev ने INP सुधारने के लिए guidance दी, जो अक्सर सामान्य performance best practices तक पहुँचती है: लंबे tasks को तोड़ना, भारी computation के लिए web workers का उपयोग करना, आदि
  • FID से INP की ओर बदलाव, CWV team की उस सोच को रेखांकित करता है जिसमें ज्यादा महत्वपूर्ण चीजों को बेहतर तरीके से कवर करने के लिए metrics को लगातार दोहराया और सुधारा जाता है
    • इस मामले में, सिर्फ page load नहीं बल्कि पूरी user visit के दौरान consistent responsiveness सुनिश्चित करना

स्मूदनेस और animation

  • Chrome team ने जिस दूसरे पहलू की जांच की, वह था animation frame rate और scroll jank जैसी visual smoothness
  • यह अभी आधिकारिक CWV metric नहीं है, लेकिन इस पर काम जारी है
  • Chrome team ने RUM tools को Smoothness metric देना शुरू किया, जिसे कभी-कभी CrUX में "Jankiness" के रूप में रिपोर्ट किया जाता है, ताकि अटकती animations जैसी चीजों को quantify किया जा सके
  • browser में jank कम करने के लिए heuristics भी जोड़े गए
    • उदाहरण के लिए, touch events को display frame के साथ synchronize करने के तरीके को adjust करके Android पर Chrome की अपनी scrolling smoothness को दोगुना किया गया था, जैसा कि अगस्त 2023 की Fast and Curious पोस्ट में विस्तार से बताया गया
  • भविष्य में संभव है कि कोई आधिकारिक "smoothness" Web Vital दिखे, या INP को कुछ खास animation delays को कवर करने के लिए बढ़ाया जाए
  • मुख्य बात यह है कि Google इन पहलुओं को पहचानता है और उन पर सक्रिय रूप से प्रयोग कर रहा है

Soft Navigation(SPA)

  • शुरुआती CWV definition की एक सीमा यह थी कि उसका फोकस पूरे page load पर था, जिसे तथाकथित "hard navigation" कहा जाता है
  • लेकिन आधुनिक Single-Page Applications(SPA) अक्सर एक बार load होती हैं और फिर पूरे reload के बिना content और routes को dynamically update करती हैं
  • ऐसी soft navigation — जहाँ link click करने पर पूरा browser navigation नहीं होता बल्कि JavaScript के जरिए content बदलता है — मूल implementation में LCP या CLS measurement में capture नहीं होती थी
    • browser के नज़रिए से यह अब भी वही पेज रहता है, इसलिए बड़ा DOM update नया LCP trigger नहीं करता
  • इसका मतलब था कि SPA के मामले में developers को app के भीतर "page transitions" को evaluate करने के लिए custom measurements पर निर्भर रहना पड़ता था, और CrUX(field) data भी इन बाद की navigations के लिए blind रहता था; सिर्फ शुरुआती page load CWV रिकॉर्ड होता था
  • इसे ठीक करने के लिए Chrome ने Soft Navigation API प्रस्तावित किया
    • इस काम का पूरा श्रेय Yoav Weiss को
    • 2023 के मध्य में Chrome ने heuristics के जरिए SPA navigations को detect करने के experiment शुरू किए
    • 2025 के मध्य तक Soft Navigations API के लिए origin trial जारी किया गया
  • जैसा कि Chrome engineers Barry Pollard और Michal Mocny ने समझाया, soft navigation वह स्थिति है जहाँ "JavaScript navigation को intercept करता है, जैसे History API या framework router के जरिए, और full reload के बिना history.pushState से URL update करते हुए मौजूदा पेज का content बदल देता है"
  • नए API की मदद से browser और developers इन events को mark कर सकते हैं और मूलतः उन्हें नए page view की तरह treat कर सकते हैं
  • सबसे महत्वपूर्ण बात, इससे soft route changes को page load की तरह मानते हुए SPA में Core Web Vitals measure करना संभव होता है
  • API का उपयोग करने पर LCP जैसे metrics soft navigation पर reset हो सकते हैं और नए view का सबसे बड़ा content capture कर सकते हैं; इसके लिए Performance Timeline में "interaction-to-next-paint" entry की अवधारणा इस्तेमाल होती है
  • इसी तरह CLS को per-navigation आधार पर विभाजित किया जा सकता है और INP को मौजूदा view से जोड़ा जा सकता है
  • यह client-side routing apps की दुनिया में CWV लाने की दिशा में बहुत बड़ी प्रगति है, और ऐसे apps अब बहुत सामान्य हैं
  • 2025 के अंत तक Soft Nav API अभी trial में है, और developers opt-in करके feedback भेज सकते हैं
  • समय के साथ उम्मीद है कि Chrome soft nav metrics को पूरी तरह support करेगा और field data(CrUX) भी उन्हें शामिल करेगा
  • यह विकास इस बात को स्वीकार करता है कि user journey कई चरणों से बनी होती है, सिर्फ landing page load से नहीं, और web platform को पूरी यात्रा को measure और optimize करना चाहिए

भविष्य का विकास

  • Google ने संकेत दिया है कि वह metrics को हर साल आगे भी बेहतर बनाता रहेगा
  • हमें नए thresholds जैसे बदलाव देखने को मिल सकते हैं
    • उदाहरण के लिए, अगर web समग्र रूप से और तेज हो जाता है, तो भविष्य में "good" LCP target 2.5 सेकंड से भी ज्यादा सख्त हो सकता है
    • या फिर अगर कोई स्पष्ट कमी सामने आती है, तो बिल्कुल नया metric आ सकता है
  • सभी नए additions एक public process से गुजरते हैं, जैसे web performance standards की परिभाषा और दूसरे browser vendors के साथ चर्चा, जैसा INP के मामले में हुआ
  • Google समय के साथ और ज्यादा page experience signals को integrate करने की योजना रखता है
    • उदाहरण के लिए, privacy और security से जुड़े ऐसे experiments, जिनमें अगर कोई site अच्छी practices अपनाती है तो Chrome के जरिए "fast page" badge दिखाया जाए
  • लेकिन Search ranking के संदर्भ में Google ने हाल के वर्षों में messaging को सरल किया है
    • 2023 तक उसने कहा कि individual signals से परे कोई अलग से स्पष्ट "page experience" ranking booster नहीं होगा
    • मूल रूप से page experience considerations को core ranking algorithm में अधिक सूक्ष्म तरीके से integrate किया गया
    • लेकिन site owners के नज़रिए से कुछ भी नहीं बदलता
    • तेज़, responsive और stable pages user satisfaction और अच्छे SEO, दोनों के लिए बुनियादी रूप से महत्वपूर्ण हैं

निष्कर्ष

  • Core Web Vitals का इतिहास web platform के चुनौतियों के अनुरूप विकसित होने की कहानी है
    • इसकी शुरुआत इस समझ से हुई कि user experience quality को मापा जा सकता है और उसे महत्व मिलना चाहिए, और यह metrics, browsers, search ranking, tools, frameworks और hosting platforms तक फैले एक बड़े आंदोलन में बदल गया
    • कुछ ही वर्षों में इसने पूरे web performance ecosystem में महत्वपूर्ण सुधारों को आगे बढ़ाया
    • यह यात्रा अभी जारी है: SPA के लिए soft navigation measurement और metrics के लगातार refinement जैसे आने वाले innovations दिखाते हैं कि तेज़ और सुखद web experience के लिए industry की प्रतिबद्धता अब भी मजबूत है
  • Core Web Vitals सिर्फ metrics का एक सेट नहीं, बल्कि एक ज्यादा स्वस्थ, तेज़ और user-centric web के लिए catalyst साबित हुआ है
    • यह कई लोगों के सहयोग से बनी विरासत है, और ऐसी विरासत है जिससे web इस्तेमाल करने वाला हर व्यक्ति लाभ उठाएगा

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.