Core Web Vitals para sa online store: LCP, INP at CLS

Ano ang sinusukat ng LCP, INP at CLS, ang good at poor na threshold sa ika-75 percentile, lab vs field data, at karaniwang ayos sa Shopify at WooCommerce.

Pangkat Editoryal ng FixReports14 minutong pagbasa

Ang Core Web Vitals ay tatlong metric ng Google na naglalarawan kung paano nararanasan ng totoong mga bisita ang isang page: Largest Contentful Paint (LCP) para sa pag-load, Interaction to Next Paint (INP) para sa pagiging responsive, at Cumulative Layout Shift (CLS) para sa visual stability. Pumapasa ang isang page kapag hindi bababa sa 75% ng mga pagbisita ang nasa "good" range: LCP sa loob ng 2.5 segundo, INP sa loob ng 200 millisecond at CLS na 0.1 o mas mababa, na sinusukat nang hiwalay para sa mobile at desktop. Sa mga online store, kadalasang nag-uugat ang bagsak na score sa malalaki o naka-lazy-load na hero at product image, mga script ng app at tracking, mga web font, at mga banner o review widget na nagtutulak pababa sa content matapos lumabas ang page.

Mga pangunahing punto

Ano ang mga threshold ng Core Web Vitals?

Pumapasa ang isang page sa Core Web Vitals kapag nasa good range ang ika-75 percentile ng mga page load nito para sa lahat ng tatlong metric.

MetricAno ang sinusukat nitoGoodNeeds improvementPoor
LCPOras hanggang mag-render ang pinakamalaking larawan, video o block ng text sa viewport2.5 s o mas mababaLampas 2.5 s hanggang 4.0 sLampas 4.0 s
INPOras mula sa click, tap o pagpindot ng key hanggang ma-paint ang susunod na frame200 ms o mas mababaLampas 200 ms hanggang 500 msLampas 500 ms
CLSGaano kalaki ang hindi inaasahang paggalaw ng nakikitang content0.1 o mas mababaLampas 0.1 hanggang 0.25Lampas 0.25

Mula sa mga gabay ng web.dev para sa LCP (magbubukas sa bagong tab), INP (magbubukas sa bagong tab) at CLS (magbubukas sa bagong tab) ang mga threshold, hanggang Oktubre 2026.

Ang ika-75 percentile ay nangangahulugang sumasalamin ang resulta sa karamihan ng mga bisita, hindi lang sa pinakamabibilis, at hinihiwalay ng Google ang mobile at desktop (magbubukas sa bagong tab). Pumapasa ang isang page sa PageSpeed Insights kapag good ang lahat ng tatlong metric; kapag kulang ang INP data, LCP at CLS lang ang hinuhusgahan nito (PageSpeed Insights docs (magbubukas sa bagong tab)). Sinasabi ng Google na hindi magbabago ang mga stable na Core Web Vitals nang higit sa isang beses kada taon.

Sa isang store, kadalasang ang hero banner o ang pangunahing larawan ng produkto ang LCP element, kaya napakahalaga ng paghawak sa mga larawan.

Bakit pinalitan ng INP ang FID noong Marso 2024?

Pinalitan ng INP ang FID dahil ang unang interaction lang at bahagi lang ng delay nito ang sinusukat ng FID, samantalang tinitingnan ng INP ang mga interaction sa buong pagbisita.

Inanunsiyo ng Google noong Mayo 2023 na magiging Core Web Vital ang INP, at nagkabisa ang pagpapalit noong Marso 12, 2024 (magbubukas sa bagong tab). Iniuulat lang ng FID ang unang interaction, at ang input delay lang nito, hindi ang oras na ginugol sa pagpapatakbo ng mga event handler o sa pag-paint ng resulta. Inoobserbahan ng INP ang mga click, tap at pagpindot ng key sa buong pagbisita at iniuulat ang pinakamatagal, nang hindi isinasama ang mga outlier; hindi binibilang ang pag-scroll at pag-hover. Hanggang Setyembre 9, 2024 ang palugit sa mga gumagamit ng CrUX at PageSpeed Insights API para lumipat (web.dev (magbubukas sa bagong tab)).

May tatlong bahagi ang bawat interaction: input delay (paghihintay sa mga abalang script), processing duration (pagpapatakbo ng mga handler) at presentation delay (pag-paint ng susunod na frame) (web.dev (magbubukas sa bagong tab)).

Sa isang store, ang mga interaction na ito ay ang variant picker, mga button ng quantity, add to cart, cart drawer, mga filter at menu. Puwedeng pumasa ang isang page sa FID dahil mabilis ang unang tap pero mabagal pa ring maramdaman kapag binuksan ng isang tao ang mga filter sa kalaunan.

Ano ang pagkakaiba ng lab data at field data?

Galing ang lab data sa isang test sa ilalim ng mga nakapirming kondisyon, samantalang kinokolekta ang field data mula sa totoong mga bisita sa paglipas ng panahon, at inirerekomenda ng Google na gamitin ang field data sa pagpapasya kung ano ang uunahing ayusin (web.dev (magbubukas sa bagong tab)).

Lab dataField data
PinagmulanIsang simulated na page load (Lighthouse, Chrome DevTools, ang lab section ng PageSpeed Insights)Totoong mga bisita sa Chrome (Chrome UX Report), o sarili mong real user monitoring
Mga kondisyonNakapirming device at network. Gumagamit ang default na mobile test ng Lighthouse (magbubukas sa bagong tab) ng "Slow 4G" (150 ms round trip, 1.6 Mbps down) at 4x na pagpapabagal ng CPUAnumang device, network at lokasyon ng iyong mga bisita
INPHindi nasusukat sa simpleng page load. Ang Total Blocking Time (TBT) ay magaspang na pamalitSinusukat mula sa totoong mga interaction
Pinakamainam para saPag-debug at pag-check ng isang pagbabago bago i-releasePag-alam kung ano talaga ang nararanasan ng mga bisita

Pinagsasama ng TBT ang bahagi ng bawat main-thread task na lampas sa 50 ms; iminumungkahi ng web.dev na mas mababa ito sa 200 ms sa karaniwang mobile hardware, pero sinasabi nitong hindi ito pamalit sa INP (web.dev (magbubukas sa bagong tab)).

Tatlong detalye ng Chrome UX Report (CrUX) ang mahalaga para sa mga store:

  • Isa itong rolling average ng 28 araw (magbubukas sa bagong tab), na ina-update araw-araw.
  • Saklaw nito ang Chrome sa desktop at Android para sa mga user na pasok sa mga kondisyon ng Chrome sa pag-uulat. Hindi kasama ang Chrome sa iOS, kaya ang store na karamihan ng mamimili ay naka-iPhone ay may field data mula sa bahagi lang ng audience nito (methodology (magbubukas sa bagong tab)).
  • Lumalabas lang ang mga page at origin kapag publicly discoverable ang mga ito at sapat ang dami ng bisita, kaya maaaring origin-level data lang, o wala talaga, ang store na kaunti ang traffic.

Nag-uulat din ang web performance dashboard (magbubukas sa bagong tab) ng Shopify ng real-user na LCP, INP at CLS sa ika-75 percentile, sa loob ng 30 araw sa halip na 28, kaya asahan ang ilang pagkakaiba sa CrUX.

Ano ang nagpapabagal sa LCP sa mga page ng store?

Kadalasang mabagal ang LCP sa mga store dahil masyadong mabigat ang pangunahing larawan, huli itong natutuklasan, o sadyang naaantala ito ng lazy loading o ng isang animation.

  • Pag-lazy-load sa LCP image. Sinasabi ng web.dev na huwag na huwag itong gawin (web.dev (magbubukas sa bagong tab)). Sa pagsusuri nito sa mga WordPress page, mas mabagal ang LCP sa ika-75 percentile sa mga site na gumagamit ng native lazy loading, at nawala ang pagbagal nang hindi na i-lazy-load ang mga larawang above the fold (web.dev (magbubukas sa bagong tab)).
  • Larawang huli nang natuklasan. Ang hero na naka-set bilang CSS background-image, o ini-inject ng isang slider script, ay wala sa HTML na unang sina-scan ng browser. Pinapayuhan ng Shopify na huwag gumamit ng CSS background para sa hero content at ng fade-in effect sa LCP image (Shopify (magbubukas sa bagong tab)).
  • Mababang priority. Naglo-load ang mga larawan sa mababang priority hangga't hindi tapos ang layout, kaya inirerekomenda ng Shopify ang fetchpriority="high" sa LCP image (Shopify (magbubukas sa bagong tab)). Ayon sa web.dev, nababawasan ang silbi nito kapag inilagay sa higit sa isa o dalawang larawan (web.dev (magbubukas sa bagong tab)).
  • Render-blocking na CSS at script. Naaantala ng malalaking stylesheet at synchronous script sa <head> ang rendering kahit dumating na ang larawan (web.dev (magbubukas sa bagong tab)).
  • Laki ng file at mga font. Gumamit ng modernong format, srcset at sizes, at CDN. Para sa mga web font, gumamit ng font-display value na hindi auto o block.
<!-- 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">

Ano ang nagpapabagal sa INP sa mga page ng store?

Kadalasang ibig sabihin ng mabagal na INP sa mga store ay sobrang daming JavaScript sa main thread, na karamihan ay galing sa mga app, tracking tag at feature ng theme, kaya kailangang maghintay ng mga tap.

Kung mag-tap ang isang mamimili sa "Add to cart" habang tumatakbo pa ang mga script ng review, chat at analytics, maghihintay ang tap. Nagdadagdag ng processing time ang variant picker na nire-render ulit ang buong product form. Nagdadagdag naman ng presentation delay ang malalaking mega menu at mga collection grid na maraming swatch.

Inirerekomenda ng web.dev na hatiin ang mahahabang task at magbigay-daan (yield) sa main thread, i-update muna ang screen at ipagpaliban ang iba, at panatilihing mas maliit ang DOM (web.dev (magbubukas sa bagong tab)). Nagdadagdag ang Shopify ng mga hakbang na partikular sa store: i-audit ang bawat app, pixel at script ng theme, ipagpaliban ang hindi kritikal, i-load ang mga feature kapag may interaction, at i-off ang mga anti-flicker snippet ng A/B testing kapag walang tumatakbong test (Shopify (magbubukas sa bagong tab)).

Ano ang sanhi ng layout shift sa mga product at collection page?

Kadalasang galing ang layout shift sa mga store sa content na lumalabas o nagbabago ang laki matapos ang unang render: mga larawang walang dimensyon, announcement at cookie bar, review widget, app block at font swap.

Inililista ng web.dev ang mga karaniwang sanhi: media na hindi alam ang dimensyon, content na idinagdag sa itaas ng kasalukuyang content, mga third-party widget na nagbabago ng sariling laki, at mga web font na iba ang laki sa kanilang fallback (web.dev (magbubukas sa bagong tab)). Sa mga store, ibig sabihin nito ay free-shipping bar na isinisingit sa itaas, mga star rating na naglo-load pagkatapos ng title, mensahe tungkol sa hulugan (installment) sa ilalim ng presyo, at mga recommendation carousel. Ayon sa Shopify, puwede ring magdulot ng shift ang pop-up content (Shopify (magbubukas sa bagong tab)).

Hindi binibilang ang mga shift sa loob ng 500 ms matapos ang input ng user, pero binibilang ang mga shift habang nag-i-scroll, at madalas itong hindi nakikita ng mga lab tool (web.dev (magbubukas sa bagong tab)). Lagyan ng width at height o CSS aspect-ratio ang mga larawan, maglaan ng espasyo para sa mga widget, ipakita ang mga banner bilang overlay, bawasan ang shift mula sa font swap gamit ang size-adjust, at mag-animate gamit ang transform sa halip na top o left.

/* 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; }

Paano pagagandahin ang Core Web Vitals sa Shopify?

Sa Shopify, karamihan ng pag-unlad ay galing sa pag-load sa unang larawan nang eager at high priority, pagbabawas ng mga app script, at pag-check sa resulta sa mga web performance report ng admin.

Tingnan ang data sa iyong admin

May lumalabas na buod sa page na Online Store > Themes, at nasa Analytics > Reports ang buong report ng LCP, INP at CLS. Maaaring maantala ang data nang hanggang 36 oras, at kailangang naka-off ang private mode (Shopify Help Center (magbubukas sa bagong tab)).

Kontrolin ang pag-load ng larawan sa Liquid

Nila-lazy-load ng image_tag filter ang mga larawan sa mga section na nasa ibaba ng page maliban kung i-set mo ang preload (image_tag reference (magbubukas sa bagong tab)): eager para sa section 1 hanggang 3, lazy mula section 4. Dahil nil ang section.index sa theme editor, mag-test gamit ang > 3 sa halip na <= 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 -%}

Sa mga product grid, iminumungkahi ng Shopify na i-eager load lang ang unang ilang card (halimbawa forloop.index <= 4) (Shopify (magbubukas sa bagong tab)). Gamitin nang matipid ang preload: true; inirerekomenda ng Shopify na i-preload lang ang isa o dalawang resource na huling natutuklasan.

Alisin ang mga iniiwan ng mga app

I-off ang mga hindi ginagamit na app embed sa Online Store > Edit theme > App embeds (Shopify Help Center (magbubukas sa bagong tab)). Kapag in-uninstall ang isang app, naaalis ang mga app block nito, pero ang mga app na direktang nag-edit ng mga file ng theme ay maaaring mag-iwan ng "ghost code" na ayon sa Shopify ay maaaring magdulot ng mga isyu sa kalidad at performance (Shopify (magbubukas sa bagong tab)). Sinasabi rin ng Shopify na titigil sa pagtakbo ang mga script tag sa Marso 1, 2027. Para sa mga font, inirerekomenda ng Shopify ang sarili nitong CDN o mga system font kaysa sa mga external na font service (Shopify (magbubukas sa bagong tab)).

Paano pagagandahin ang Core Web Vitals sa WooCommerce?

Sa WooCommerce, siguraduhing hindi ino-override ng mga plugin ang pag-prioritize ng WordPress sa mga larawan, i-cache ang lahat maliban sa cart at checkout, at alisin ang mga script na naglo-load kahit saan nang hindi kailangan.

  • Panatilihin ang image handling ng core. Mula WordPress 6.3 (inilabas noong Agosto 8, 2023), nagdadagdag ang core ng fetchpriority="high" sa malamang na LCP image (hindi bababa sa 50,000 square pixel bilang default) at hindi nito nila-lazy-load ang unang tatlong content image (Make WordPress Core (magbubukas sa bagong tab)). Kung may sariling lazy loading ang isang optimization plugin, tiyaking hindi nito sinasaklaw ang hero at ang pangunahing larawan ng produkto.
  • I-cache ang mga page, hindi ang mga cart. Inirerekomenda ng gabay ng WooCommerce ang page caching sa server o sa plugin at ang paggamit ng CDN, habang hindi naka-cache ang mga page ng cart at checkout (WooCommerce developer docs (magbubukas sa bagong tab)).
  • Suriin ang cart fragments. Mula WooCommerce 7.8, naglo-load lang ang cart fragments script kung saan may Cart widget, pero may mga theme na naka-hard-code ang widget na iyon. Hindi gumagamit ng cart fragments ang Mini-Cart block (WooCommerce developer blog (magbubukas sa bagong tab)).
  • Hanapin ang mabibigat na plugin. Iminumungkahi ng WooCommerce ang Query Monitor para mahanap ang mabagal na plugin, at ang pagpapaliban sa hindi kritikal na JavaScript.

Kung higit sa tatlong larawan ang ipinapakita ng iyong layout above the fold, puwede mong taasan ang threshold ng 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;
} );

Gaano katagal bago makita ang epekto ng mga ayos?

Agad na ipinapakita ng mga lab test ang epekto ng isang ayos, pero kailangan ng field data ng hanggang mga apat na linggo para ganap itong maipakita, dahil ina-average ng CrUX ang nakaraang 28 araw.

Patakbuhin ang lab test nang ilang beses bago at pagkatapos ng isang pagbabago, dahil nag-iiba-iba ang bawat run, saka bantayan ang field numbers sa PageSpeed Insights, sa Core Web Vitals report ng Search Console o sa mga report ng Shopify. Ang isang libreng scan ay nagbibigay ng unang pagtingin sa loob ng mga isang minuto. Ang Ulat sa Bilis ng Website ay nagpapatakbo ng throttled na mobile lab test (slow 4G, 4x CPU) at nagdadagdag ng field data ng Chrome UX Report, kasama ang INP kapag may sapat na data ang Google para sa iyong store.

Mga madalas itanong

Nakakaapekto ba ang Core Web Vitals sa ranking sa Google?

Sinasabi ng Google na ginagamit ng mga ranking system nito ang Core Web Vitals, pero hindi ginagarantiya ng magandang score ang pinakamataas na ranking, at ipinapakita pa rin nito ang pinaka-relevant na content kahit hindi maganda ang page experience (Google Search Central (magbubukas sa bagong tab)).

Bakit walang field data ang store ko sa PageSpeed Insights?

Kasama lang sa CrUX ang mga page at origin na publicly discoverable at may sapat na kwalipikadong bisita sa Chrome. Ang store na kaunti ang traffic ay maaaring may origin-level data lang, o wala talaga, kaya umasa sa mga lab test at sa sariling report ng iyong platform.

Kailangan ko ba ng Lighthouse score na 90 pataas para pumasa?

Hindi. Lab result ang Lighthouse performance score, samantalang field data sa ika-75 percentile ang ginagamit ng Core Web Vitals assessment, kaya puwedeng pumasa ang isang page kahit katamtaman ang Lighthouse score nito at bumagsak kahit mataas ito.

Dapat ko bang i-lazy-load ang lahat ng larawan ng produkto?

Hindi. I-lazy-load ang mga larawan sa ibaba ng unang screen, pero i-load nang eager ang hero at ang pangunahing larawan ng produkto, na may fetchpriority="high" sa isa sa mga ito.

Bakit mas mahina ang resulta ko sa mobile kaysa sa desktop?

Hiwalay na sinusukat ng Google ang mobile at desktop, at mas mabagal ang processor at network ng mga phone. Sinisimulate ito ng mobile test ng Lighthouse gamit ang Slow 4G profile at 4x na pagpapabagal ng CPU.

Mga sanggunian

Lahat ng gabay