Core Web Vitals for e-commerce: what breaks LCP, INP and CLS on product and category pages

In an online shop, Core Web Vitals are won or lost on templates: product page, category page and home page. What breaks them most is a lazy-loaded main image (LCP), images and banners with no reserved space (CLS) and third-party scripts on filters and buttons (INP). Google rates them good at LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1.

To check it on your own site: Online shops

This guide sticks to what is specific to a shop; the rest of the work is in the guide to e-commerce SEO for AI search. What each metric measures on any website is in the general guide to Core Web Vitals, and how to read the report, in the one on PageSpeed Insights. A declaration of interest: this blog belongs to SmoothSeen, a web audit tool that measures visibility in search engines and AI assistants.

The thresholds, applied to a shop

Each metric covers one part of the experience: loading (LCP), interactivity (INP) and visual stability (CLS)1. Google sets a "good" threshold for each and another above which it is "poor"; in between, it "needs improvement"2. The last column is what usually sits behind each metric in a shop:

The value that counts is the 75th percentile of page loads, separately for mobile and desktop1: a template passes if three visits in four get a good experience. And the responsiveness metric is INP, which replaced FID as a Core Web Vital on 12 March 20243; an e-commerce guide that still talks about FID is out of date.

Why does a shop measure by template, not by product?

Because almost no product page has field data of its own. Field data comes from CrUX (the Chrome User Experience Report), which only includes pages that are public and have a minimum number of visitors; Google does not disclose that minimum4. A new product, or one of the hundreds that get few visits, does not qualify.

When a URL lacks enough data, PageSpeed Insights falls back to the whole origin, meaning the entire domain2. Search Console, for its part, groups URLs with a similar experience in its Core Web Vitals report, and each group takes the status of its worst metric5: a group with good LCP and poor CLS shows as "poor".

For a shop, that has three practical consequences:

1. What you see for a product page may be the domain average. If the home page is fast and product pages are slow, the average hides it.
2. Search Console's groups almost always match your templates. A "poor" group of hundreds of product URLs is the product template, not hundreds of separate problems.
3. A fix is confirmed after four weeks. When you validate a fix, Search Console starts a 28-day monitoring session5, the same window PageSpeed Insights uses for field data2.

If your domain has no field data either, work with PageSpeed Insights' lab data, which simulates the load with Lighthouse2, on one URL per template.

What breaks each metric on an online shop?

Shop templates fail in the same places again and again. This table sorts them by metric, with a source for each:

Fixes in order of impact

The order starts with what can be fixed in the template with little effort and ends with what needs more engineering. Measure each change in the lab before and after, and confirm it in field data a few weeks later.

1. Remove lazy loading from the main image. On a product page, the product photo; on a category page, the first images in the grid. The web.dev study on lazy loading found that deferring only the images below the first screen fully reversed the LCP regression12.
2. Give that image priority with fetchpriority="high"6. In a Google Flights lab test, giving the background image high priority cut LCP from 2.6 to 1.9 seconds13.
3. Set width and height on every image, or reserve the space with CSS aspect-ratio14. Formats, sizes and compression for product photos are in the guide to image SEO.
4. Reserve space for anything that arrives late (banners, notices, badges, review widgets) with min-height or aspect-ratio14.
5. Audit third-party scripts. Load anything not needed to buy with async or defer, remove what adds nothing and control who can add tags to the tag manager9. This means agreeing with marketing what stays.
6. Break up long tasks. Any task over 50 ms is a long task; yielding to the browser between chunks, for example with scheduler.yield(), lets it respond to the user sooner10.
7. Stop the autoplaying carousel or, if you keep it, pause it on hover, and move slides with transform rather than left or top7.
8. Improve the server: page caching, a CDN and hosting that matches your traffic. It costs the most, so leave it until after the rest.

What it looks like in the template

The first four points are written once in the theme and reach every product page. This snippet is a commented example; paths, sizes and class names are illustrative:

<!-- PRODUCT PAGE: the main image is usually the LCP element.
     No loading="lazy", high priority and explicit dimensions. -->
<img src="/img/moka-6-front.webp"
     alt="Six-cup aluminium stovetop espresso maker, front view"
     width="800" height="800" fetchpriority="high">

<!-- CATEGORY PAGE: images in the first row load normally;
     from the first row that sits off-screen, they are lazy-loaded. -->
<img src="/img/product-13.webp" alt="Ten-cup drip coffee maker"
     width="400" height="400" loading="lazy">

<!-- REVIEWS WIDGET injected late: space reserved before it arrives. -->
<div class="product-reviews"></div>

/* Height taken from the loaded widget, measured on mobile. */
.product-reviews { min-height: 320px; }

If your platform adds loading="lazy" to every image by default, the first point usually needs a theme change or a setting in the image module: check it in the HTML of the live product page, not in the admin panel.

Are Core Web Vitals a ranking factor?

Yes, but a tie-breaker. Google says Core Web Vitals are used by its ranking systems and recommends getting them into good shape15. On the same page it adds two caveats worth reading together15:

• Google Search always seeks to show the most relevant content, even if the page experience is sub-par.
• Good results in the Core Web Vitals report do not guarantee top rankings. Where there is plenty of helpful content available, a great page experience can contribute to success.

For a shop, that means a fast product page with a copied description will not beat a slightly slower one that answers the shopper better. Product pages, categories and markup come first; speed comes after. What a product page's markup needs is in the guide to Product schema.

What the PageSpeed score does not tell you

The 0 to 100 score in PageSpeed Insights is a lab result and changes with every run, with network availability, the testing hardware and resource contention2. A shop adds two more sources of variation, both listed in the Lighthouse documentation: A/B tests and ads that change from one load to the next16.

That score is not the Core Web Vitals assessment, either. According to the Lighthouse documentation, the metric with the most weight in it is TBT, Total Blocking Time (30%), followed by LCP and CLS (25% each)16, and TBT is a lab metric. Two rules to avoid chasing ghosts:

• Decide with field data, template by template. The score is for diagnosis.
• Repeat the lab test several times and take the median: Lighthouse says the median of five runs is twice as stable as a single run17.

SmoothSeen includes speed with Core Web Vitals, lab and field data when PageSpeed Insights has them, in the report for every page it analyses, alongside the rest of its search visibility checks. It analyses one page at a time, so for a shop it is worth giving it one URL per template; it does not replace Search Console's Core Web Vitals report.

Frequently asked questions

Which page of my shop should I measure first?

A product page and a category page from among those with the most traffic, on mobile. They are the templates shared by the most URLs: a fault in them is repeated across the whole catalogue, and so is a fix. Then the home page, if it has a carousel. Check in Search Console which URL group scores worst and start with the template behind it.

Do review, chat and advertising widgets hurt Core Web Vitals?

They can hurt two of them. If they are injected late with no space reserved, they push content around and raise CLS; if they run a lot of JavaScript on the main thread, they delay the response to clicks and raise INP. Reserve their space in CSS, load them with async or defer when they are not needed to buy, and remove the ones nobody uses.

Why does my shop have no field data?

Because CrUX only includes public pages and origins with a minimum number of visitors, a figure Google does not disclose. If a product page does not qualify, PageSpeed Insights uses data for the whole domain; if the domain does not qualify either, you will only see lab data. In the meantime, test one URL per template in the lab and repeat each test several times.

Are Core Web Vitals a ranking factor for an online shop?

Yes. Google says its ranking systems use them, but also that it always seeks to show the most relevant content even when page experience is sub-par, and that good results do not guarantee top rankings. For a shop, original descriptions, product data and a clear catalogue structure matter before speed does.

What to do next

Run PageSpeed Insights on one product page and one category page, see which metric fails in the field data block and apply the fixes in the order listed, starting with the template. Once it is sorted, go back to the guide to e-commerce SEO for AI search for the rest of the work.