ऑनलाइन स्टोर के लिए Core Web Vitals: LCP, INP और CLS आसान भाषा में

LCP, INP और CLS क्या मापते हैं, 75वें पर्सेंटाइल पर good और poor की सीमाएँ, लैब बनाम फ़ील्ड डेटा, और Shopify व WooCommerce स्टोर की स्पीड सुधारने के आम उपाय।

FixReports संपादकीय टीमपढ़ने में 14 मिनट

Core Web Vitals, Google के तीन मेट्रिक हैं जो बताते हैं कि असली विज़िटर्स को किसी पेज का अनुभव कैसा मिलता है: लोडिंग के लिए Largest Contentful Paint (LCP), रिस्पॉन्सिवनेस के लिए Interaction to Next Paint (INP) और विज़ुअल स्थिरता के लिए Cumulative Layout Shift (CLS)। कोई पेज तब पास होता है जब कम से कम 75% विज़िट "good" रेंज में हों: LCP 2.5 सेकंड के भीतर, INP 200 मिलीसेकंड के भीतर और CLS 0.1 या उससे कम, और यह मोबाइल व डेस्कटॉप के लिए अलग-अलग मापा जाता है। ऑनलाइन स्टोर पर ख़राब स्कोर की वजह आम तौर पर भारी या lazy-load की गई हीरो और प्रोडक्ट इमेज, ऐप और ट्रैकिंग स्क्रिप्ट, वेब फ़ॉन्ट, और ऐसे बैनर या रिव्यू विजेट होते हैं जो पेज दिखने के बाद कंटेंट को नीचे धकेल देते हैं।

मुख्य बातें

  • Good, needs improvement और poor का फ़ैसला पेज लोड के 75वें पर्सेंटाइल पर होता है: LCP 4 सेकंड से ज़्यादा हो तो poor, INP 500 ms से ज़्यादा हो तो poor, और CLS 0.25 से ज़्यादा हो तो poor (web.dev (नए टैब में खुलता है))।
  • 12 मार्च 2024 को INP ने Core Web Vital के रूप में First Input Delay (FID) की जगह ली (web.dev (नए टैब में खुलता है))।
  • Chrome UX Report का फ़ील्ड डेटा 28 दिनों का रोलिंग औसत होता है और इसमें iOS पर चलने वाला Chrome शामिल नहीं होता (Chrome for Developers (नए टैब में खुलता है))।
  • Shopify का image_tag फ़िल्टर टेम्पलेट के पहले तीन sections में इमेज eager तरीक़े से और चौथे section से lazy तरीक़े से लोड करता है, जब तक आप इसे ओवरराइड न करें (Shopify (नए टैब में खुलता है))।
  • WordPress 6.3 से, core उस इमेज पर fetchpriority="high" जोड़ता है जिसके LCP एलिमेंट होने की संभावना उसे सबसे ज़्यादा लगती है (Make WordPress Core (नए टैब में खुलता है))।

Core Web Vitals की सीमाएँ (thresholds) क्या हैं?

कोई पेज Core Web Vitals पर तब खरा उतरता है जब उसके पेज लोड का 75वाँ पर्सेंटाइल तीनों मेट्रिक के लिए good रेंज में हो।

मेट्रिकयह क्या मापता हैGoodNeeds improvementPoor
LCPव्यूपोर्ट में सबसे बड़ी इमेज, वीडियो या टेक्स्ट ब्लॉक के रेंडर होने तक का समय2.5 s या कम2.5 s से ज़्यादा, 4.0 s तक4.0 s से ज़्यादा
INPक्लिक, टैप या की-प्रेस से लेकर अगला फ़्रेम पेंट होने तक का समय200 ms या कम200 ms से ज़्यादा, 500 ms तक500 ms से ज़्यादा
CLSदिखने वाला कंटेंट अचानक कितना खिसकता है0.1 या कम0.1 से ज़्यादा, 0.25 तक0.25 से ज़्यादा

ये सीमाएँ अक्टूबर 2026 की स्थिति के अनुसार web.dev की LCP (नए टैब में खुलता है), INP (नए टैब में खुलता है) और CLS (नए टैब में खुलता है) गाइड से ली गई हैं।

75वें पर्सेंटाइल का मतलब है कि नतीजा सिर्फ़ सबसे तेज़ विज़िटर्स को नहीं, बल्कि ज़्यादातर विज़िटर्स को दर्शाता है, और Google मोबाइल और डेस्कटॉप को अलग-अलग (नए टैब में खुलता है) गिनता है। PageSpeed Insights किसी पेज को तब पास करता है जब तीनों मेट्रिक good हों; अगर INP का पर्याप्त डेटा न हो, तो वह सिर्फ़ LCP और CLS के आधार पर फ़ैसला करता है (PageSpeed Insights docs (नए टैब में खुलता है))। Google का कहना है कि स्थिर (stable) Core Web Vitals साल में एक बार से ज़्यादा नहीं बदलेंगे।

स्टोर पर LCP एलिमेंट अक्सर हीरो बैनर या मुख्य प्रोडक्ट इमेज होता है, इसीलिए इमेज को सही ढंग से संभालना इतना अहम है।

मार्च 2024 में INP ने FID की जगह क्यों ली?

INP ने FID की जगह इसलिए ली क्योंकि FID सिर्फ़ पहले इंटरैक्शन और उसकी देरी के एक हिस्से को मापता था, जबकि INP पूरी विज़िट के दौरान हुए इंटरैक्शन को देखता है।

Google ने मई 2023 में घोषणा की थी कि INP एक Core Web Vital बनेगा, और यह बदलाव 12 मार्च 2024 (नए टैब में खुलता है) को लागू हुआ। FID सिर्फ़ पहले इंटरैक्शन की रिपोर्ट देता था, और वह भी सिर्फ़ उसकी input delay की, इवेंट हैंडलर चलाने या नतीजा पेंट करने में लगे समय की नहीं। INP पूरी विज़िट के दौरान क्लिक, टैप और की-प्रेस को देखता है और असामान्य अपवादों (outliers) को छोड़कर सबसे लंबे इंटरैक्शन की रिपोर्ट देता है; स्क्रॉल करना और होवर करना इसमें नहीं गिना जाता। CrUX और PageSpeed Insights API के उपयोगकर्ताओं के पास बदलाव करने के लिए 9 सितंबर 2024 तक का समय था (web.dev (नए टैब में खुलता है))।

हर इंटरैक्शन के तीन हिस्से होते हैं: input delay (व्यस्त स्क्रिप्ट के ख़त्म होने का इंतज़ार), processing duration (हैंडलर चलाना) और presentation delay (अगला फ़्रेम पेंट करना) (web.dev (नए टैब में खुलता है))।

स्टोर पर ये इंटरैक्शन होते हैं वैरिएंट पिकर, क्वांटिटी बटन, ऐड टू कार्ट, कार्ट ड्रॉअर, फ़िल्टर और मेन्यू। कोई पेज पहले तेज़ टैप पर FID पास कर सकता था, फिर भी बाद में कोई फ़िल्टर खोलने पर धीमा लग सकता था।

लैब डेटा और फ़ील्ड डेटा में क्या फ़र्क़ है?

लैब डेटा तय परिस्थितियों में किए गए एक टेस्ट से आता है, जबकि फ़ील्ड डेटा समय के साथ असली विज़िटर्स से इकट्ठा होता है, और Google सलाह देता है कि पहले क्या ठीक करना है यह तय करने के लिए फ़ील्ड डेटा का इस्तेमाल करें (web.dev (नए टैब में खुलता है))।

लैब डेटाफ़ील्ड डेटा
स्रोतएक सिम्युलेटेड पेज लोड (Lighthouse, Chrome DevTools, PageSpeed Insights का लैब सेक्शन)असली Chrome विज़िटर्स (Chrome UX Report), या आपकी अपनी real user monitoring
परिस्थितियाँतय डिवाइस और नेटवर्क। Lighthouse का डिफ़ॉल्ट मोबाइल टेस्ट (नए टैब में खुलता है) "Slow 4G" (150 ms राउंड ट्रिप, 1.6 Mbps डाउनलोड) और 4x CPU स्लोडाउन इस्तेमाल करता हैआपके विज़िटर्स के जो भी डिवाइस, नेटवर्क और लोकेशन हों
INPसाधारण पेज लोड पर नहीं मापा जाता। Total Blocking Time (TBT) एक मोटा-मोटा विकल्प (proxy) हैअसली इंटरैक्शन से मापा जाता है
किसके लिए सबसे अच्छाडीबगिंग और रिलीज़ से पहले किसी बदलाव की जाँचयह जानना कि विज़िटर्स को असल में क्या अनुभव मिलता है

TBT हर main-thread टास्क के 50 ms से ऊपर वाले हिस्से को जोड़ता है; web.dev औसत मोबाइल हार्डवेयर पर इसे 200 ms से कम रखने का सुझाव देता है, लेकिन कहता है कि यह INP का विकल्प नहीं है (web.dev (नए टैब में खुलता है))।

Chrome UX Report (CrUX) की तीन बातें स्टोर के लिए अहम हैं:

  • यह 28 दिनों का रोलिंग औसत (नए टैब में खुलता है) है, जो रोज़ अपडेट होता है।
  • इसमें डेस्कटॉप और Android पर Chrome के वे उपयोगकर्ता शामिल होते हैं जो Chrome की रिपोर्टिंग शर्तें पूरी करते हैं। iOS पर Chrome शामिल नहीं है, इसलिए जिस स्टोर के ज़्यादातर ग्राहक iPhone इस्तेमाल करते हैं, उसे अपनी ऑडियंस के सिर्फ़ एक हिस्से का फ़ील्ड डेटा दिखता है (methodology (नए टैब में खुलता है))।
  • पेज और origin तभी दिखते हैं जब वे सार्वजनिक रूप से खोजे जा सकें और पर्याप्त लोकप्रिय हों, इसलिए कम ट्रैफ़िक वाले स्टोर के पास सिर्फ़ origin-स्तर का डेटा हो सकता है, या कोई डेटा नहीं।

Shopify का web performance dashboard (नए टैब में खुलता है) भी 75वें पर्सेंटाइल पर असली उपयोगकर्ताओं का LCP, INP और CLS दिखाता है, लेकिन 28 की जगह 30 दिनों के आधार पर, इसलिए CrUX से कुछ अंतर की उम्मीद रखें।

स्टोर पेजों पर LCP को क्या धीमा करता है?

स्टोर पर LCP आम तौर पर इसलिए धीमा होता है क्योंकि मुख्य इमेज बहुत भारी होती है, ब्राउज़र को देर से मिलती है, या lazy loading या किसी एनिमेशन से जानबूझकर देर से लोड होती है।

  • LCP इमेज को lazy-load करना। web.dev कहता है कि ऐसा कभी न करें (web.dev (नए टैब में खुलता है))। WordPress पेजों के उसके विश्लेषण में पाया गया कि native lazy loading इस्तेमाल करने वाली साइटों पर 75वें पर्सेंटाइल का LCP धीमा था, और above-the-fold इमेज को lazy-load न करने से यह गिरावट ख़त्म हो गई (web.dev (नए टैब में खुलता है))।
  • देर से मिलने वाली इमेज। CSS background-image के रूप में सेट किया गया या किसी स्लाइडर स्क्रिप्ट से जोड़ा गया हीरो उस HTML में नहीं होता जिसे ब्राउज़र सबसे पहले स्कैन करता है। Shopify हीरो कंटेंट के लिए CSS बैकग्राउंड और LCP इमेज पर fade-in इफ़ेक्ट से बचने की सलाह देता है (Shopify (नए टैब में खुलता है))।
  • कम प्राथमिकता। लेआउट पूरा होने तक इमेज कम प्राथमिकता पर लोड होती हैं, इसलिए Shopify LCP इमेज पर fetchpriority="high" लगाने की सलाह देता है (Shopify (नए टैब में खुलता है))। web.dev के अनुसार इसे एक या दो से ज़्यादा इमेज पर लगाने से इसका फ़ायदा कम हो जाता है (web.dev (नए टैब में खुलता है))।
  • रेंडर-ब्लॉकिंग CSS और स्क्रिप्ट। <head> में बड़ी स्टाइलशीट और synchronous स्क्रिप्ट इमेज आ जाने के बाद भी रेंडरिंग में देरी करती हैं (web.dev (नए टैब में खुलता है))।
  • फ़ाइल साइज़ और फ़ॉन्ट। आधुनिक फ़ॉर्मेट, srcset और sizes, और CDN का इस्तेमाल करें। वेब फ़ॉन्ट के लिए auto या block के अलावा कोई font-display वैल्यू इस्तेमाल करें।
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

स्टोर पेजों पर INP धीमा क्यों होता है?

स्टोर पर धीमे INP का मतलब आम तौर पर यह होता है कि main thread पर बहुत ज़्यादा JavaScript है, जिसका बड़ा हिस्सा ऐप्स, ट्रैकिंग टैग और थीम फ़ीचर्स से आता है, इसलिए टैप को इंतज़ार करना पड़ता है।

अगर कोई ग्राहक "Add to cart" पर टैप करता है और उसी समय रिव्यू, चैट और एनालिटिक्स स्क्रिप्ट चल रही होती हैं, तो टैप को इंतज़ार करना पड़ता है। जो वैरिएंट पिकर पूरे प्रोडक्ट फ़ॉर्म को दोबारा रेंडर करता है, वह processing time बढ़ाता है। बहुत बड़े मेगा मेन्यू और कई swatches वाले कलेक्शन ग्रिड presentation delay बढ़ाते हैं।

web.dev लंबे टास्क को तोड़ने और main thread को बीच-बीच में मौक़ा देने (yielding), पहले स्क्रीन अपडेट करने और बाक़ी काम बाद के लिए टालने, और DOM को छोटा रखने की सलाह देता है (web.dev (नए टैब में खुलता है))। Shopify स्टोर के लिए ख़ास कदम जोड़ता है: हर ऐप, पिक्सेल और थीम स्क्रिप्ट का ऑडिट करें, जो ज़रूरी नहीं है उसे defer करें, फ़ीचर्स को इंटरैक्शन होने पर लोड करें, और जब कोई टेस्ट न चल रहा हो तो A/B टेस्टिंग के anti-flicker snippets बंद कर दें (Shopify (नए टैब में खुलता है))।

प्रोडक्ट और कलेक्शन पेजों पर लेआउट शिफ़्ट क्यों होते हैं?

स्टोर पर लेआउट शिफ़्ट ज़्यादातर उस कंटेंट से होते हैं जो पहले रेंडर के बाद दिखता है या अपना आकार बदलता है: बिना डाइमेंशन वाली इमेज, अनाउंसमेंट और कुकी बार, रिव्यू विजेट, ऐप ब्लॉक और फ़ॉन्ट स्वैप।

web.dev के अनुसार आम कारण हैं अज्ञात डाइमेंशन वाला मीडिया, मौजूदा कंटेंट के ऊपर जोड़ा गया कंटेंट, अपना आकार ख़ुद बदलने वाले थर्ड-पार्टी विजेट, और ऐसे वेब फ़ॉन्ट जिनका आकार उनके fallback फ़ॉन्ट से अलग होता है (web.dev (नए टैब में खुलता है))। स्टोर पर इसका मतलब है सबसे ऊपर जोड़ा गया फ़्री-शिपिंग बार, टाइटल के बाद लोड होने वाली स्टार रेटिंग, कीमत के नीचे किस्तों (installment) वाला संदेश, और रिकमेंडेशन कैरोसेल। Shopify बताता है कि पॉप-अप कंटेंट से भी शिफ़्ट हो सकते हैं (Shopify (नए टैब में खुलता है))।

उपयोगकर्ता के इनपुट के 500 ms के भीतर होने वाले शिफ़्ट नहीं गिने जाते, लेकिन स्क्रॉल करते समय होने वाले शिफ़्ट गिने जाते हैं, और लैब टूल अक्सर उन्हें पकड़ नहीं पाते (web.dev (नए टैब में खुलता है))। इमेज को width और height या CSS aspect-ratio दें, विजेट के लिए जगह पहले से रिज़र्व करें, बैनर को overlay के रूप में दिखाएँ, size-adjust से फ़ॉन्ट स्वैप वाले शिफ़्ट कम करें, और एनिमेशन के लिए top या left की जगह transform इस्तेमाल करें।

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Shopify पर Core Web Vitals कैसे सुधारें?

Shopify पर ज़्यादातर फ़ायदा पहली इमेज को high priority के साथ eager लोड करने, ऐप स्क्रिप्ट कम करने और admin की web performance रिपोर्ट में नतीजा जाँचने से मिलता है।

अपने admin में डेटा देखें

Online Store > Themes पेज पर एक सारांश दिखता है, और LCP, INP और CLS की पूरी रिपोर्ट Analytics > Reports में होती हैं। डेटा में 36 घंटे तक की देरी हो सकती है, और private mode बंद होना चाहिए (Shopify Help Center (नए टैब में खुलता है))।

Liquid में इमेज लोडिंग नियंत्रित करें

image_tag फ़िल्टर पेज में नीचे वाले sections की इमेज को lazy-load करता है, जब तक आप preload सेट न करें (image_tag reference (नए टैब में खुलता है)): section 1 से 3 के लिए eager, section 4 से lazy। चूँकि थीम एडिटर में section.index की वैल्यू nil होती है, इसलिए <= 3 की जगह > 3 से जाँच करें:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

प्रोडक्ट ग्रिड में Shopify सिर्फ़ पहले कुछ कार्ड्स को eager लोड करने का सुझाव देता है (उदाहरण के लिए forloop.index <= 4) (Shopify (नए टैब में खुलता है))। preload: true का इस्तेमाल कम से कम करें; Shopify सिर्फ़ एक या दो देर से मिलने वाले रिसोर्स को preload करने की सलाह देता है।

ऐप्स जो छोड़ जाते हैं उसे हटाएँ

Online Store > Edit theme > App embeds में इस्तेमाल न होने वाले app embeds बंद करें (Shopify Help Center (नए टैब में खुलता है))। किसी ऐप को अनइंस्टॉल करने से उसके app blocks हट जाते हैं, लेकिन जिन ऐप्स ने थीम फ़ाइलों में सीधे बदलाव किए थे, वे "ghost code" छोड़ सकते हैं, जिसके बारे में Shopify कहता है कि इससे क्वालिटी और परफ़ॉर्मेंस की समस्याएँ हो सकती हैं (Shopify (नए टैब में खुलता है))। Shopify यह भी कहता है कि script tags 1 मार्च 2027 से चलना बंद हो जाएँगे। फ़ॉन्ट के लिए Shopify बाहरी फ़ॉन्ट सेवाओं की बजाय अपने CDN या सिस्टम फ़ॉन्ट की सलाह देता है (Shopify (नए टैब में खुलता है))।

WooCommerce पर Core Web Vitals कैसे सुधारें?

WooCommerce पर सुनिश्चित करें कि प्लगइन WordPress की इमेज प्राथमिकता को ओवरराइड न करें, कार्ट और चेकआउट को छोड़कर सब कुछ कैश करें, और बेवजह हर जगह लोड होने वाली स्क्रिप्ट हटाएँ।

  • core की इमेज हैंडलिंग बनाए रखें। WordPress 6.3 (8 अगस्त 2023 को रिलीज़) से, core संभावित LCP इमेज (डिफ़ॉल्ट रूप से कम से कम 50,000 वर्ग पिक्सेल) पर fetchpriority="high" जोड़ता है और पहली तीन कंटेंट इमेज के लिए lazy loading छोड़ देता है (Make WordPress Core (नए टैब में खुलता है))। अगर कोई ऑप्टिमाइज़ेशन प्लगइन अपनी lazy loading जोड़ता है, तो जाँचें कि वह हीरो और मुख्य प्रोडक्ट इमेज को इससे बाहर रखता है।
  • पेज कैश करें, कार्ट नहीं। WooCommerce की गाइड सर्वर या प्लगइन से पेज कैशिंग और CDN की सलाह देती है, लेकिन कार्ट और चेकआउट पेज को अनकैश्ड रखने को कहती है (WooCommerce developer docs (नए टैब में खुलता है))।
  • cart fragments जाँचें। WooCommerce 7.8 से, cart fragments स्क्रिप्ट सिर्फ़ वहीं लोड होती है जहाँ Cart विजेट मौजूद हो, लेकिन कुछ थीम उस विजेट को hard-code कर देती हैं। Mini-Cart ब्लॉक cart fragments इस्तेमाल नहीं करता (WooCommerce developer blog (नए टैब में खुलता है))।
  • भारी प्लगइन ढूँढें। WooCommerce धीमे प्लगइन ढूँढने के लिए Query Monitor और ग़ैर-ज़रूरी JavaScript को defer करने का सुझाव देता है।

अगर आपके लेआउट में above the fold तीन से ज़्यादा इमेज दिखती हैं, तो आप WordPress की यह सीमा बढ़ा सकते हैं:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

सुधार का असर दिखने में कितना समय लगता है?

लैब टेस्ट किसी सुधार का असर तुरंत दिखाते हैं, लेकिन फ़ील्ड डेटा में इसे पूरी तरह दिखने में लगभग चार हफ़्ते तक लग सकते हैं, क्योंकि CrUX पिछले 28 दिनों का औसत लेता है।

किसी बदलाव से पहले और बाद में लैब टेस्ट कई बार चलाएँ, क्योंकि हर रन का नतीजा अलग हो सकता है, फिर PageSpeed Insights, Search Console की Core Web Vitals रिपोर्ट या Shopify की रिपोर्ट में फ़ील्ड आँकड़ों पर नज़र रखें। मुफ़्त स्कैन लगभग एक मिनट में पहली झलक देता है। परफ़ॉर्मेंस सुधार रिपोर्ट एक थ्रॉटल्ड मोबाइल लैब टेस्ट (slow 4G, 4x CPU) चलाती है और Chrome UX Report का फ़ील्ड डेटा जोड़ती है, जिसमें INP भी शामिल है, बशर्ते Google के पास आपके स्टोर का पर्याप्त डेटा हो।

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

क्या Core Web Vitals से Google रैंकिंग पर असर पड़ता है?

Google का कहना है कि Core Web Vitals उसके रैंकिंग सिस्टम में इस्तेमाल होते हैं, लेकिन अच्छे स्कोर टॉप रैंकिंग की गारंटी नहीं देते, और page experience ख़राब होने पर भी वह सबसे प्रासंगिक कंटेंट ही दिखाता है (Google Search Central (नए टैब में खुलता है))।

PageSpeed Insights मेरे स्टोर के लिए कोई फ़ील्ड डेटा क्यों नहीं दिखाता?

CrUX में सिर्फ़ वे पेज और origin शामिल होते हैं जो सार्वजनिक रूप से खोजे जा सकते हैं और जिनके पास पर्याप्त योग्य Chrome विज़िटर हैं। कम ट्रैफ़िक वाले स्टोर के पास सिर्फ़ origin-स्तर का डेटा हो सकता है, या कोई डेटा नहीं, इसलिए लैब टेस्ट और अपने प्लेटफ़ॉर्म की रिपोर्ट पर भरोसा करें।

क्या पास होने के लिए Lighthouse स्कोर 90 या उससे ज़्यादा होना चाहिए?

नहीं। Lighthouse का परफ़ॉर्मेंस स्कोर एक लैब नतीजा है, जबकि Core Web Vitals का आकलन 75वें पर्सेंटाइल पर फ़ील्ड डेटा से होता है, इसलिए कोई पेज मामूली Lighthouse स्कोर के साथ पास हो सकता है और ऊँचे स्कोर के साथ फ़ेल भी।

क्या मुझे सभी प्रोडक्ट इमेज lazy-load करनी चाहिए?

नहीं। पहली स्क्रीन के नीचे वाली इमेज lazy-load करें, लेकिन हीरो और मुख्य प्रोडक्ट इमेज को eager लोड करें, और उनमें से किसी एक पर fetchpriority="high" लगाएँ।

मेरे मोबाइल नतीजे डेस्कटॉप से ख़राब क्यों हैं?

Google मोबाइल और डेस्कटॉप को अलग-अलग मापता है, और फ़ोन के प्रोसेसर और नेटवर्क धीमे होते हैं। Lighthouse का मोबाइल टेस्ट Slow 4G प्रोफ़ाइल और 4x CPU स्लोडाउन से इसी स्थिति की नक़ल करता है।

स्रोत

सभी गाइड