Core Web Vitals, explained for store owners

The CIQRA team29 September 2026 8 min read

Core Web Vitals are three metrics Google uses to measure how a page feels to real visitors: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A store page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. This guide explains each metric in store terms, how to measure it, and which fixes tend to matter most on product and category pages.

The three metrics at a glance

Google publishes a "good", "needs improvement" and "poor" band for each metric. These are the figures from web.dev, Google's developer guidance:

MetricWhat it measuresGoodNeeds improvementPoor
LCPHow quickly the main content appears2.5 s or less2.5 s to 4.0 sOver 4.0 s
INPHow quickly the page responds to taps, clicks and key presses200 ms or less200 ms to 500 msOver 500 ms
CLSHow much the layout jumps while the page is in use0.1 or less0.1 to 0.25Over 0.25

Two details are easy to miss. First, Google recommends judging each metric at the 75th percentile of page loads, segmented by mobile and desktop. In other words, it is not enough for the page to be fast on your office Wi-Fi; three out of four real visits should hit the target. Second, the set of metrics changes over time. INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, so older guides that still talk about FID are out of date.

What each metric means on a store

LCP: when the product actually shows up

LCP records when the largest image or text block in the viewport finishes rendering. On a product page that is usually the main product photo; on a home or collection page it is often a hero banner. Elements that count include images, video poster images, background images set in CSS, and large blocks of text.

Google's optimization guide splits LCP into four parts: time to first byte (how long the server takes to start responding), resource load delay (how long before the browser starts fetching the LCP image), resource load duration (how long that image takes to download), and element render delay (the gap before it is painted). A slow LCP on a store is most often a large, late-discovered hero image or a slow server response.

INP: whether the page reacts when a shopper taps

INP looks at the clicks, taps and key presses a visitor makes during the whole visit and reports one of the slowest. Hovering, scrolling and zooming do not count. On a store, the interactions that matter are the ones shoppers make constantly: choosing a size or color, opening a filter, changing the quantity, pressing "Add to cart" and typing into search. Each interaction has three phases: input delay (waiting for the browser's main thread to be free), processing time (your code running), and presentation delay (painting the result). Heavy JavaScript from themes, apps and tags usually shows up here.

CLS: whether the button moves under the finger

CLS adds up unexpected layout shifts. The classic store example is a shopper reaching for "Add to cart" just as a banner, review widget or late image pushes the button down. Web.dev lists the usual causes: images and videos without set dimensions, ads and embeds that resize themselves, web fonts that render at a different size from their fallback, and content injected above what the visitor is already reading. Shifts that happen within 500 milliseconds of a click, tap or key press are excluded, so an accordion that opens when tapped is not penalized.

Do Core Web Vitals affect rankings?

Yes, but they are not a shortcut to the top of the results. Google Search Central states that Core Web Vitals "are used by our ranking systems", and also that there is no single page experience signal. Google says it will still show the most relevant content even when the page experience is sub-par, and that good scores in Search Console or third-party tools do not guarantee top rankings.

For a store owner, the practical reading is simple. Relevance and useful product content come first. Page experience helps when several pages are similarly relevant, and it matters for the shoppers who do arrive, whether they came from search, ads or email.

Why speed matters for sales

The link between responsiveness and shopping behavior is measurable. In a case study published on web.dev in December 2023, the marketplace Trendyol reported cutting INP on its product listing page by 50% and seeing a 1% uplift in click-through from the listing page to product pages per user session. The main work was breaking long JavaScript tasks into smaller pieces so the page could respond to taps sooner. Results vary by store, so treat a case study as a reason to measure your own pages rather than as a forecast.

How to measure your store

There are two kinds of data, and both are useful:

  • Field data comes from real visitors. The Chrome User Experience Report (CrUX) collects it from eligible Chrome users, and it is what you see in PageSpeed Insights and the Core Web Vitals report in Google Search Console. Pages need enough traffic to have their own field data; smaller pages may only show origin-level data or none at all.
  • Lab data comes from a simulated visit in a tool such as Lighthouse or Chrome DevTools. It is repeatable, which makes it good for testing a fix before release. Lighthouse cannot measure INP directly because nobody is clicking; it reports Total Blocking Time as a proxy.

A sensible routine: check the Search Console report to find which groups of URLs fail (often product or collection templates), open a representative URL in PageSpeed Insights to see the field numbers, then use Lighthouse or DevTools to find the cause and confirm the fix. Because stores share templates, fixing one product template usually fixes thousands of URLs at once.

Fixes that matter most on store pages

Improve LCP

  • Make the main image discoverable early. Put the hero or main product image in the HTML as a normal image, not something injected later by JavaScript or hidden in CSS. Add fetchpriority="high" to it.
  • Never lazy-load the LCP image. Google's guide is blunt: lazy-loading it always adds delay. Lazy-load images further down the page instead.
  • Serve right-sized, modern images. Use formats such as AVIF and WebP and deliver a size that suits the device.
  • Cut server response time. Serve pages from a CDN close to shoppers and cache HTML where you can, even briefly. Server-side rendering helps the browser find the main image in the first response.

Improve INP

  • Audit third-party scripts. Every widget, chat tool and tag competes for the same main thread. Remove what nobody uses.
  • Break up long tasks. Split heavy work, such as re-rendering a product grid after a filter change, into smaller chunks that yield to the browser between steps.
  • Ship less JavaScript. Use code splitting and native browser features where possible, and keep the page's DOM from growing very large.

Improve CLS

  • Reserve space for media. Set width and height on images and videos, or use CSS aspect-ratio, so the layout is correct before the file arrives.
  • Give late content a home. Promo bars, review stars and recommendation carousels should load into a reserved slot rather than pushing content down.
  • Animate with transforms. Animating margin or top moves the layout; animating transform does not.
  • Keep pages eligible for the back/forward cache. Shoppers go back and forth between listings and products constantly, and a page restored from the bfcache shows up instantly with no layout shift.

How CIQRA approaches storefront speed

On CIQRA, storefront pages are built on the server rather than in the browser and served from a global edge network close to each visitor. Images are converted to AVIF and WebP and resized automatically, and page speed and layout shift are tracked regularly so fixes follow the numbers. After one such performance pass in September 2026, a live store's desktop Lighthouse score went from 41 to 83 and its layout shift fell from 0.646 to 0.004. Those are lab measurements for one store; your own field data in Search Console remains the figure to watch.

FAQ

What are good Core Web Vitals scores?

LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real page loads on mobile and desktop separately.

Is FID still a Core Web Vital?

No. INP replaced FID on March 12, 2024.

Why does PageSpeed Insights show different numbers from Lighthouse?

PageSpeed Insights shows field data from real Chrome users when enough is available, alongside a Lighthouse lab run. The lab run is a single simulated visit, so it will not match what real shoppers experience on their own devices and networks.

Will passing Core Web Vitals move my store to the top of Google?

Not on its own. Google uses Core Web Vitals in its ranking systems but says good scores do not guarantee top rankings; relevance and helpful content come first.

Sources

Share LinkedIn X Facebook Email

Written by
The CIQRA team

Related articles