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

Your product page feels fast, yet Search Console shows red bars and mobile visitors drop off. That gap almost always comes from the same thing: you test on a good device over Wi-Fi, and Google measures what real visitors experience. This article explains what LCP, INP and CLS actually capture, where the numbers come from, and in which order to fix the bottlenecks typical of online stores.

The three metrics in plain terms

Core Web Vitals are three measurements Google uses to put the experience on a page into numbers. How quickly do I see something? How quickly does the page react to me? Does the layout jump around?

LCP: Largest Contentful Paint

LCP measures when the largest visible element in the initial viewport finishes rendering. In stores that is almost always the main product image, a category hero or a large headline. The documented target is 2.5 seconds or less, counted from the moment the page starts loading; above 4 seconds it counts as poor.

Important distinction: LCP is not "load time". It is the moment the visitor gets the impression that the page has arrived. A skeleton placeholder helps the feeling but does not improve LCP if the real image still needs three more seconds.

INP: Interaction to Next Paint

INP measures how long it takes from an input, whether a click, tap or keypress, to the next visible response. It does not report the first interaction but effectively the slowest relevant one in a visit. The documented target is 200 milliseconds or less; above 500 milliseconds counts as poor. Chrome announced that INP would replace First Input Delay as a Core Web Vital on 12 March 2024, and FID was removed from Search Console on that date. INP is the stricter metric: it is no longer enough that the first click is accepted, the page has to visibly answer.

Typical store cases: choosing a variant, applying a filter, tapping "Add to cart", opening the menu. When a lot of JavaScript runs during any of those, the value goes bad.

CLS: Cumulative Layout Shift

CLS measures how much content moves after the fact without the visitor causing it. The documented target is 0.1 or less; above 0.25 counts as poor. The classic example: you reach for "Add to cart" and at that instant a banner loads above the button, so your tap lands somewhere else.

All three targets, and the rule that a page is assessed at the 75th percentile of page loads split across mobile and desktop, are documented on web.dev's Core Web Vitals page.

Field data and lab data: why the numbers disagree

This is where most internal arguments start. There are two sources and they answer different questions.

Three consequences follow:

• The 75th percentile decides. If three out of four loads are good, you pass. A very fast average does not help when a quarter of your visitors are on older phones over mobile networks.
• Mobile and desktop are assessed separately. Almost every store problem is a mobile problem.
• INP is missing from the lab test. Lighthouse cannot measure INP because nobody clicks. Instead it reports things like long main-thread tasks: useful, but not a substitute.

Your tools, all free: the Core Web Vitals report in Search Console, PageSpeed Insights for a single URL with field and lab data side by side, and the Web Vitals extension for Chrome, which shows you live which interaction is hanging while you click through your own checkout.

One detail that saves time: Search Console groups URLs with a similar structure. When "product pages" are red, you do not have to touch 4,000 pages. You have to fix one template.

The usual bottlenecks in an online store

Images

Product images are almost always the LCP element and the single biggest lever. Common mistakes: a 2,400-pixel-wide file is displayed at 380 pixels on a phone, the format is still JPEG instead of WebP or AVIF, and the most important image sits behind lazy loading even though it is immediately visible.

What helps: serve appropriate sizes with srcset and sizes, use modern formats, always set width and height (that alone removes a large share of CLS), and for the first visible image remove loading="lazy" and set fetchpriority="high" instead.

Fonts

Two separate problems. If text only appears once the font has loaded, LCP moves back. If a system font is shown first and then swapped, the layout shifts and CLS rises. Both get defused by self-hosting the font files, preloading them, using font-display: swap, and matching the fallback font's metrics with size-adjust. And two weights are almost always enough, not six.

Apps, scripts and widgets

This is the most common cause of poor INP. Every app that injects scripts into your store, whether reviews, chat, consent banner, newsletter popups, A/B testing or several tracking tools, occupies the main thread. The result: the tap on "Add to cart" registers, but the response arrives late.

Take inventory. Which app produces measurable revenue and which one is just historical? Scripts that are not needed immediately belong behind defer or after the first render. A chat widget can load on the first click on a lightweight placeholder icon.

Sliders, banners and consent notices

A slider above the fold is bad three ways: it loads several large images, brings its own JavaScript, and usually shifts content. Consent banners and promo bars injected via JavaScript push the rest of the page down, which is a guaranteed CLS hit. The fix is to reserve the space in the layout or show them as an overlay instead of changing the flow. Where consent is legally required and how it must behave is a question for your lawyer or data protection officer, not a performance decision.

Server and cache

If the first server response is already slow, every other optimization is capped. Causes are usually uncached category pages with many filters, slow database queries or hosting without a CDN. On hosted platforms like Shopify you have less influence here and more influence over the theme and the apps, which is where the Shopify SEO guide picks the thread up.

Step by step: a two-week approach

1. Take stock. Open the Core Web Vitals report in Search Console, Mobile tab. Note the URL groups marked "poor" or "needs improvement" and how many URLs each covers.
2. Templates, not pages. Pick one representative URL per group: the homepage, one category page, one product page, one guide. You do not need more.
3. One PageSpeed Insights run per URL. Read the field data at the top first, then the diagnostics below. For each URL write down: which element is the LCP element, which resources block rendering, which elements shift.
4. Sort by effort. Put the findings in two columns. "Quick and safe" covers image sizes, width/height, fetchpriority, fixing lazy loading, removing an unused app. "Needs development" covers theme rebuilds, caching, splitting JavaScript.
5. Ship the quick column. All of it in one pass. In practice that handles the bulk of LCP and CLS.
6. Verify before and after in the lab test. Same URL, same conditions, Lighthouse in mobile mode. The lab test confirms the change works technically.
7. Test INP by hand. On a real, preferably slow phone: switch variants, apply filters, add to cart, open the menu. Note where it hangs and find the scripts responsible.
8. Check field data after two weeks. Only then does the 28-day value move visibly. When you have fixed a group in Search Console, you can start the validation.

Checklist for the product page

• The main image is not lazy-loaded and carries fetchpriority="high".
• Every image has width and height, or a fixed aspect ratio in CSS.
• Images are served as WebP or AVIF in several sizes.
• At most two font weights, self-hosted, preloaded, with font-display: swap.
• The consent banner and promo bars do not push content around.
• No slider above the fold; one static image is enough.
• App scripts are deferred or loaded on demand.
• One tracking setup only, no leftover duplicate tags from old installations.
• Tested on a phone, not just in a desktop browser with a narrow window.
• After the rebuild: search, filters and internal links still intact.

What to realistically expect

Core Web Vitals are one signal among many. A fast page with the wrong content does not rank, and moving from "good" to "excellent" buys you very little in search. The real payoff is elsewhere: visitors who do not have to wait abandon less often. So when you take a group of pages from red to green, watch what happens to mobile drop-off and orders at the same time. The metric that makes that visible is covered in ecommerce conversion rate, and the checkout-specific side in reduce cart abandonment.

And repeat the measurement rather than doing it once. Every new app, every new banner and every theme update can undo your work. In ecomando the values from the SEO audit sit next to your store metrics, so a regression is visible before it shows up in Search Console. If you would rather work without extra tooling, put a monthly appointment in your calendar and check the four template URLs by hand.

If you are just getting started with technical SEO, read the overview in the ecommerce SEO guide first. Core Web Vitals are the finishing work, not the starting point.