Core Web Vitals in ecommerce: what to measure and what to fix first

By Julián, founder of Rankedora · 2 November 2026 · 8 min read

A slow or unstable online store doesn’t just annoy the shopper: it also costs you orders. Google measures real loading experience with three metrics called Core Web Vitals, and uses them as one of its page experience signals. It helps to put them in their place: they are not a magic shortcut to climb rankings, because Google insists that content relevance weighs more, but a store with poor numbers loses visits and sales even if it ranks well. This guide helps you measure what matters and not lose weeks on what moves nothing.

The three metrics and their thresholds

Google assesses each metric at the 75th percentile of real visits, separately on mobile and desktop. In other words, for a page to be considered good, three out of four visits must meet the threshold. INP replaced the old FID as the interactivity metric in March 2024, and it is the one that fails most often in stores with many third-party scripts.

Where to measure them and with what data

• Search Console, Core Web Vitals report: uses field data, that is, from real users, and groups URLs by type of problem. It is the starting point because it tells you which groups of pages fail.
• PageSpeed Insights: shows the URL’s field data when there are enough visits and, separately, a lab simulation with Lighthouse for diagnosis. The two may not match, and field data is what counts for Google.
• Your own data: if you have a lot of traffic, you can collect the metrics in your analytics with Google’s web-vitals library to see which templates and which devices suffer most.

Always measure per template: home page, category, product page, cart and checkout. That is what makes it actionable. A fix on the product page template improves thousands of URLs at once.

LCP: what usually slows loading in a store

On a product page or a category, the main element is usually the product image or the header banner. What helps most:

• Don’t lazy-load the main image. It is a very common mistake: what is seen first must be requested first. You can indicate its priority with fetchpriority='high'.
• Serve the image at the actual size it is displayed and in a modern format such as WebP or AVIF.
• Reduce server response time: hosting, caching and fewer heavy queries on categories with filters.
• Remove CSS and JavaScript that block rendering before the first content.
• Load fonts with a strategy that doesn’t delay the main text.

INP: almost always a scripts problem

INP gets worse when the browser is busy running JavaScript just when the user wants to tap. In a store, the typical culprits are:

• Tag managers with many marketing tags and accumulated pixels.
• Chat, reviews, loyalty programme, pop-up and personalisation widgets.
• Filters and search boxes that repaint the whole list with every click.
• Add-to-cart events that run too many actions in a row.

The approach is always the same: remove what adds nothing, delay what isn’t needed on load and split long tasks. Many stores have scripts from tools they stopped using years ago that still load on every page.

CLS: the jumps that make clicks fail

• Images and videos with no declared width and height, which push the content as they load.
• Banners, free-shipping bars and cookie notices that are injected later and shift the page.
• Review stars or prices that appear late and change the height of the block.
• Fonts that change the size of the text when they swap.

The solution is to reserve the space for each element before it loads.

Where to start depending on your platform

A six-step sprint

1. Open the Core Web Vitals report in Search Console and note which URL groups fail on mobile.
2. Pick one template and analyse a representative URL in PageSpeed Insights.
3. Identify the LCP element, the costliest scripts and the elements that shift.
4. Fix first what affects many pages: main image, global scripts, reserved space.
5. Publish the changes and wait. The field report uses data from the last few weeks, so you won’t see the improvement instantly.
6. Repeat with the next template and measure again every time you install an app or plugin.

What not to do

• Chasing a 100 in the lab simulation. What counts is field data and real experience.
• Optimising only the home page and forgetting product pages and categories.
• Installing a speed-up app that adds more JavaScript than it removes.
• Measuring right after a change and drawing conclusions before there is enough data.

Quick checklist

• Metrics reviewed on mobile and per template.
• Main image not lazy-loaded and with high priority.
• Images with declared dimensions and in a modern format.
• Third-party scripts audited and reduced.
• Space reserved for banners, reviews and notices.
• Measured again after every new app or plugin.

Frequently asked questions

Sources consulted

• web.dev: Web Vitals
• web.dev: Interaction to Next Paint (INP)
• web.dev: optimise Largest Contentful Paint
• Google Search Central: Core Web Vitals and Google Search