Core Web Vitals for online stores: LCP, INP and CLS explained

What LCP, INP and CLS measure, the good and poor thresholds at the 75th percentile, lab vs field data, and the usual fixes on Shopify and WooCommerce stores.

FixReports editorial team12 min read

Core Web Vitals are three Google metrics that describe how real visitors experience a page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when at least 75% of visits are in the "good" range: LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less, measured separately for mobile and desktop. On online stores, failing scores usually trace back to large or lazy-loaded hero and product images, app and tracking scripts, web fonts, and banners or review widgets that push content down after the page appears.

Key points

What are the Core Web Vitals thresholds?

A page meets the Core Web Vitals when the 75th percentile of its page loads falls in the good range for all three metrics.

MetricWhat it measuresGoodNeeds improvementPoor
LCPTime until the largest image, video or text block in the viewport renders2.5 s or lessOver 2.5 s up to 4.0 sOver 4.0 s
INPTime from a click, tap or key press until the next frame is painted200 ms or lessOver 200 ms up to 500 msOver 500 ms
CLSHow much visible content moves unexpectedly0.1 or lessOver 0.1 up to 0.25Over 0.25

Thresholds are from web.dev's LCP (opens in a new tab), INP (opens in a new tab) and CLS (opens in a new tab) guides, as of October 2026.

The 75th percentile means the result reflects most visitors, not just the fastest, and Google segments mobile and desktop (opens in a new tab). PageSpeed Insights passes a page when all three metrics are good; without enough INP data, it judges LCP and CLS alone (PageSpeed Insights docs (opens in a new tab)). Google says stable Core Web Vitals won't change more than once per year.

On a store, the LCP element is often the hero banner or the main product image, which is why image handling matters so much.

Why did INP replace FID in March 2024?

INP replaced FID because FID measured only the first interaction and only part of its delay, while INP looks at interactions across the whole visit.

Google announced in May 2023 that INP would become a Core Web Vital, and the switch took effect on March 12, 2024 (opens in a new tab). FID reported only the first interaction, and only its input delay, not the time spent running event handlers or painting the result. INP observes clicks, taps and key presses for the whole visit and reports the longest one, ignoring outliers; scrolling and hovering don't count. Users of the CrUX and PageSpeed Insights APIs had until September 9, 2024 to switch (web.dev (opens in a new tab)).

Each interaction has three parts: input delay (waiting for busy scripts), processing duration (running the handlers) and presentation delay (painting the next frame) (web.dev (opens in a new tab)).

On a store, those interactions are the variant picker, quantity buttons, add to cart, cart drawer, filters and menus. A page could pass FID on a quick first tap and still feel slow when someone opens the filters later.

What is the difference between lab data and field data?

Lab data comes from one test under fixed conditions, while field data is collected from real visitors over time, and Google recommends using field data to decide what to fix first (web.dev (opens in a new tab)).

Lab dataField data
SourceOne simulated page load (Lighthouse, Chrome DevTools, the lab section of PageSpeed Insights)Real Chrome visitors (Chrome UX Report), or your own real user monitoring
ConditionsFixed device and network. Lighthouse's default mobile test (opens in a new tab) uses "Slow 4G" (150 ms round trip, 1.6 Mbps down) and a 4x CPU slowdownWhatever devices, networks and locations your visitors have
INPNot measured on a plain page load. Total Blocking Time (TBT) is a rough proxyMeasured from real interactions
Best forDebugging and checking a change before releaseKnowing what visitors actually get

TBT adds up the part of each main-thread task beyond 50 ms; web.dev suggests under 200 ms on average mobile hardware but says it is no substitute for INP (web.dev (opens in a new tab)).

Three details of the Chrome UX Report (CrUX) matter for stores:

  • It is a 28-day rolling average (opens in a new tab), updated daily.
  • It covers Chrome on desktop and Android for users who meet Chrome's reporting conditions. Chrome on iOS is excluded, so a store with mostly iPhone shoppers sees field data from only part of its audience (methodology (opens in a new tab)).
  • Pages and origins appear only when they are publicly discoverable and popular enough, so a low-traffic store may have origin-level data only, or none.

Shopify's web performance dashboard (opens in a new tab) also reports real-user LCP, INP and CLS at the 75th percentile, over 30 days rather than 28, so expect some differences from CrUX.

What slows down LCP on store pages?

LCP is usually slow on stores because the main image is too heavy, discovered late, or deliberately delayed by lazy loading or an animation.

  • Lazy-loading the LCP image. web.dev says never to do this (web.dev (opens in a new tab)). Its analysis of WordPress pages found slower 75th-percentile LCP on sites using native lazy loading, and not lazy-loading above-the-fold images removed the regression (web.dev (opens in a new tab)).
  • An image found late. A hero set as a CSS background-image, or injected by a slider script, is not in the HTML the browser first scans. Shopify advises against CSS backgrounds for hero content and fade-in effects on the LCP image (Shopify (opens in a new tab)).
  • Low priority. Images load at low priority until layout is complete, so Shopify recommends fetchpriority="high" on the LCP image (Shopify (opens in a new tab)). web.dev notes that setting it on more than one or two images reduces its usefulness (web.dev (opens in a new tab)).
  • Render-blocking CSS and scripts. Large stylesheets and synchronous scripts in the <head> delay rendering even after the image arrives (web.dev (opens in a new tab)).
  • File size and fonts. Use modern formats, srcset and sizes, and a CDN. For web fonts, use a font-display value other than auto or 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">

What makes INP slow on store pages?

Slow INP on stores usually means too much JavaScript on the main thread, much of it from apps, tracking tags and theme features, so taps have to wait.

If a shopper taps "Add to cart" while review, chat and analytics scripts are still running, the tap waits. A variant picker that re-renders the whole product form adds processing time. Huge mega menus and collection grids with many swatches add presentation delay.

web.dev recommends breaking up long tasks and yielding to the main thread, updating the screen first and deferring the rest, and keeping the DOM smaller (web.dev (opens in a new tab)). Shopify adds store-specific steps: audit every app, pixel and theme script, defer what isn't critical, load features on interaction, and turn off A/B testing anti-flicker snippets when no test is running (Shopify (opens in a new tab)).

What causes layout shifts on product and collection pages?

Layout shifts on stores mostly come from content that appears or resizes after the first render: images without dimensions, announcement and cookie bars, review widgets, app blocks and font swaps.

web.dev lists the common causes as media with unknown dimensions, content added above existing content, third-party widgets that resize themselves, and web fonts that differ in size from their fallback (web.dev (opens in a new tab)). On stores that means a free-shipping bar inserted at the top, star ratings that load after the title, installment messaging under the price, and recommendation carousels. Shopify notes that pop-up content can also cause shifts (Shopify (opens in a new tab)).

Shifts within 500 ms of a user's input don't count, but shifts while scrolling do, and lab tools often miss them (web.dev (opens in a new tab)). Give images width and height or a CSS aspect-ratio, reserve space for widgets, show banners as overlays, reduce font swap shifts with size-adjust, and animate with transform rather than top or 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; }

How do you improve Core Web Vitals on Shopify?

On Shopify, most gains come from loading the first image eagerly with high priority, trimming app scripts, and checking the result in the admin's web performance reports.

Check the data in your admin

A summary appears on the Online Store > Themes page, and full LCP, INP and CLS reports are under Analytics > Reports. The data can be delayed by up to 36 hours, and private mode must be off (Shopify Help Center (opens in a new tab)).

Control image loading in Liquid

The image_tag filter lazy-loads images in sections further down the page unless you set preload (image_tag reference (opens in a new tab)): eager for sections 1 to 3, lazy from section 4. Because section.index is nil in the theme editor, test with > 3 rather than <= 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 -%}

In product grids, Shopify suggests eager loading only the first few cards (for example forloop.index <= 4) (Shopify (opens in a new tab)). Use preload: true sparingly; Shopify recommends preloading only one or two late-discovered resources.

Remove what apps leave behind

Turn off unused app embeds under Online Store > Edit theme > App embeds (Shopify Help Center (opens in a new tab)). Uninstalling an app removes its app blocks, but apps that edited theme files directly can leave "ghost code" that Shopify says can cause quality and performance issues (Shopify (opens in a new tab)). Shopify also says script tags will stop running on March 1, 2027. For fonts, Shopify recommends its own CDN or system fonts over external font services (Shopify (opens in a new tab)).

How do you improve Core Web Vitals on WooCommerce?

On WooCommerce, make sure plugins don't override WordPress's image prioritization, cache everything except cart and checkout, and remove scripts that load everywhere without need.

  • Keep core's image handling. Since WordPress 6.3 (released August 8, 2023), core adds fetchpriority="high" to the likely LCP image (at least 50,000 square pixels by default) and skips lazy loading for the first three content images (Make WordPress Core (opens in a new tab)). If an optimization plugin adds its own lazy loading, check that it excludes the hero and the main product image.
  • Cache pages, not carts. WooCommerce's guide recommends server or plugin page caching and a CDN, while keeping cart and checkout pages uncached (WooCommerce developer docs (opens in a new tab)).
  • Check cart fragments. Since WooCommerce 7.8, the cart fragments script loads only where a Cart widget is present, but some themes hard-code that widget. The Mini-Cart block does not use cart fragments (WooCommerce developer blog (opens in a new tab)).
  • Find heavy plugins. WooCommerce suggests Query Monitor to find slow plugins, and deferring non-critical JavaScript.

If your layout shows more than three images above the fold, you can raise WordPress's threshold:

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

How long does it take for fixes to show up?

Lab tests show the effect of a fix right away, but field data needs up to about four weeks to reflect it fully, because CrUX averages the previous 28 days.

Run the lab test several times before and after a change, because single runs vary, then watch field numbers in PageSpeed Insights, Search Console's Core Web Vitals report or Shopify's reports. A free scan gives a first read in about a minute. The Performance Fix Report runs a throttled mobile lab test (slow 4G, 4x CPU) and adds Chrome UX Report field data, including INP when Google has enough data for your store.

Frequently asked questions

Do Core Web Vitals affect Google rankings?

Google says Core Web Vitals are used by its ranking systems, but that good scores do not guarantee top rankings and that it still shows the most relevant content even when page experience is poor (Google Search Central (opens in a new tab)).

Why does PageSpeed Insights show no field data for my store?

CrUX includes only pages and origins that are publicly discoverable and have enough eligible Chrome visitors. A low-traffic store may have origin-level data only, or none, so rely on lab tests and your platform's own reports.

Do I need a Lighthouse score of 90 or more to pass?

No. The Lighthouse performance score is a lab result, while the Core Web Vitals assessment uses field data at the 75th percentile, so a page can pass with a modest Lighthouse score and fail with a high one.

Should I lazy-load all product images?

No. Lazy-load images below the first screen, but load the hero and main product image eagerly, with fetchpriority="high" on one of them.

Why are my mobile results worse than desktop?

Google measures mobile and desktop separately, and phones have slower processors and networks. Lighthouse's mobile test simulates that with a Slow 4G profile and a 4x CPU slowdown.

Sources

All guides