Core Web Vitals for e-shops: LCP, INP and CLS in practice

Core Web Vitals are the three metrics Google uses to assess user experience on a page. For an e-shop they aren't just "an SEO thing": a slow or jumpy site loses sales, especially on mobile, where most traffic happens. Let's skip the theory and focus on what we actually fix.

The three metrics, one paragraph each

LCP (Largest Contentful Paint): how quickly the largest element on screen appears. On a shop it's usually the main product photo or the homepage hero. Good: up to 2.5 seconds.

INP (Interaction to Next Paint): how quickly the page responds when the user taps something: a filter, "Add to cart", a size picker. It replaced the older FID. Good: up to 200 ms.

CLS (Cumulative Layout Shift): how much content moves around while loading. The classic case: you go to tap a button and it drops down because a banner loaded above it. Good: up to 0.1.

Google judges whether a page passes at the 75th percentile of real visits, meaning 75% of your visitors need a good experience.

Where to measure (and why the numbers differ)

• Field data (real users): the Core Web Vitals report in Google Search Console and the real-user section of PageSpeed Insights. This is what counts for Google.
• Lab data (simulated): Lighthouse and the PageSpeed Insights score. Useful for diagnosis, but not what Google uses for ranking.

Don't chase a 100/100 Lighthouse score. Chase green field data on the pages that make money. For small sites without enough traffic for field data, lab data is the best guide you have.

The four templates that matter

A shop really has four templates. Fix templates, not individual pages:

1. Homepage: usually an LCP problem from a heavy slider.
2. Category: usually INP from filters and CLS from images without dimensions.
3. Product: usually LCP from the main photo and INP from variation pickers.
4. Cart/checkout: usually INP from heavy payment scripts and shipping calculations.

Fixing LCP

On a shop, the LCP element is almost always an image. Fixes in order of impact:

• Server response time (TTFB). If the server is slow to answer, everything else is slow. Page caching for anonymous visitors, decent hosting, a CDN.
• Don't lazy-load the main image. The LCP image should load immediately, ideally with fetchpriority="high".
• Right size and format. A 3000px photo for a 400px phone screen is waste. Serve WebP or AVIF with srcset.
• Drop the slider. Homepage sliders rarely get clicks past the first slide and almost always hurt LCP. One static image does the job better.
• Fonts. Fewer families and weights, font-display: swap, and self-hosted font files.

Fixing INP

INP is the metric that hurts plugin-heavy WooCommerce sites the most, because every plugin adds JavaScript.

• Fewer third-party scripts. Chat widgets, popups, heatmaps, multiple pixels: each one has a cost. Keep only what you actively use.
• Load scripts only where needed. The payment gateway script isn't needed on the homepage. The slider script isn't needed at checkout.
• Category filters. Filters that reload the whole page via heavy AJAX on every click are a frequent source of poor INP. Give instant visual feedback (a loading state) and optimise the queries.
• Variation selection. Changing size or colour should update price and photo instantly, not after a server round-trip.
• Smaller DOM. Category pages with hundreds of products and giant mega menus make every interaction slower.

Fixing CLS

CLS is usually the easiest to fix:

• Dimensions on every image (width and height, or aspect-ratio), so the browser reserves space.
• Reserved space for banners and notices. A "Free shipping over €40" bar that appears after load pushes the whole page down.
• Cookie banner as an overlay at the bottom, not a bar that shoves content.
• Fonts with metrics close to the fallback, so text doesn't jump.
• Reviews and third-party widgets with a fixed height.

A two-week plan

1. Days 1–2: Search Console, Core Web Vitals report. Which templates fail on mobile?
2. Days 3–5: TTFB and caching. If the server is slow, start there.
3. Days 6–8: Images: formats, sizes, correct lazy loading, priority for the main image.
4. Days 9–11: Scripts: inventory, removal, conditional loading.
5. Days 12–14: CLS: dimensions, banners, fonts.

Field data in Search Console takes about 28 days to fully reflect changes, so don't lose heart if you don't see green straight away.

Don't forget checkout and the admin

Core Web Vitals measure public pages, but two areas that don't always show up in the reports directly affect sales. Checkout often lacks enough traffic for field data, so test it by hand on an average phone over a slow connection: how long does switching shipping method take, or opening the card form? And the admin: if saving an order or product takes several seconds, that's almost always a sign the server is struggling, which your customers will eventually feel too.

A practical habit: after every significant change (new plugin, theme update, new tracking script), re-run PageSpeed Insights on one product page and compare it with the previous result. Regressions are much easier to fix the day they appear than three months later.

Bottom line

Core Web Vitals aren't a goal in themselves; they're a measurable way to check your shop is pleasant to use. And a pleasant shop sells more.

If you'd like to find out where your shop is losing time, our speed and Core Web Vitals service starts with a detailed audit. Get in touch for details.