Core Web Vitals are three numbers Google uses to judge how your store feels to a real customer. They measure how fast a page loads, how quickly it reacts to a tap, and whether the layout stays put instead of jumping around. It sounds technical, but the point is simple: a customer who waits too long, or taps a button that just slid down the page, closes the tab. In this article I break each of the three metrics down to its parts, point you to free measurement tools, and list the bottlenecks I keep catching in store after store during audits.

I write from the perspective of someone who checks these metrics on live stores, not on slides. So expect fewer dictionary definitions and more of what actually tanks the score, plus what you can do about it.

What Core Web Vitals are, and why your store should care

Core Web Vitals are a set of three measurable user-experience metrics that Google treats as one of its page-ranking signals. They don't replace content or links, but when two results are close in quality, they can tip the scale. In a store the stakes are higher than on a blog, because a product page is where heavy images, a handful of marketing scripts, and a cart that has to work from the first second all collide.

The three of them measure three different things: LCP (how fast I see the most important thing on screen), INP (how fast the page reacts when I tap it), and CLS (whether the layout sits still or jumps). Google publishes a "good" threshold for each, so you don't have to guess. Usually one metric drags the others down, most often because of unoptimized images or a pile of third-party scripts. It's better to first figure out which of the three is in the red and start there. Core Web Vitals also evolve over time, since Google swaps out the measured parameters every so often.

Note: FID (First Input Delay) was retired in March 2024 and replaced by INP, so any guide still treating FID as current is out of date.

LCP: how fast the customer sees what matters most

LCP (Largest Contentful Paint) measures the time it takes for the largest visible element to appear on screen. On a product page that's usually the main image or a large heading. Google considers the result good when LCP comes in under 2.5 seconds. Above that line, some people bounce straight back to the search results.

LCP usually breaks because of:

• A heavy hero image (a full-resolution file dropped straight off the camera, several megabytes).
• No modern image formats (older formats are heavier than WebP or AVIF at the same quality).
• A slow server or overloaded hosting (no amount of image optimization makes up for it).
• Rendering blocked by scripts.

What to do: compress your product images and serve them at the size they actually display, switch to a modern format, and load the main image with priority. That's usually the first move when LCP is red, because it delivers the fastest result at the lowest risk. One caveat: sometimes the largest element isn't an image but a block of text or a heading injected by a script. Check which element the tool flags as the LCP first, then pick your fix.

INP: how fast the page reacts to a tap (and why FID no longer exists)

INP (Interaction to Next Paint) measures the time between a user action (say, tapping "Add to cart") and the moment the browser shows the result. Google considers anything under 200 milliseconds good. Above that, the customer taps, nothing happens, they tap again, and the store feels frozen.

Important: INP replaced the earlier FID (First Input Delay) metric, which Google retired in March 2024. If you're reading a guide where someone still describes FID as a current parameter, that's a sign the material is outdated. INP is what counts today, because it measures the response to every interaction, not just the first one.

INP gets wrecked by:

• Too many third-party scripts (ad pixels, chat widgets, analytics, and review widgets all fight over the same browser thread).
• Heavy theme and plugin scripts.
• Everything loaded right at startup.

The biggest win comes from reviewing your third-party scripts: which ones you actually need, which can load with a delay, and which just sit there doing nothing. The catch: INP takes its hardest hit on phones, because a smartphone's processor is weaker while the store serves both devices the same heavy code. Test INP on mobile first.

CLS: does the layout sit still, or jump under your hand

CLS (Cumulative Layout Shift) measures layout stability, meaning how much elements move around while the page loads. Google considers a result good below 0.1. The classic scene: you go to tap "Buy now," a banner loads in, the button slides down, and you tap something else.

Where the jumpy layout comes from:

• Images and ad frames with no space reserved (the browser doesn't know the dimensions, draws the text, then shoves the layout aside once the graphic loads).
• Fonts that load with a delay (the swap changes the height of blocks).
• Banners, consent bars, and notifications that pop in above the content.

The recipe: reserve space for images and frames by specifying dimensions, keep font loading stable, and don't let elements pop in above the content. Watch the cookie consent banner, free-shipping bars, and newsletter pop-ups, since any element that appears after the page starts is a suspect.

How to measure Core Web Vitals for free and read the results correctly

You don't need paid tools. Google gives you the full set for free:

• PageSpeed Insights (enter a URL, get mobile and desktop scores plus recommendations, the fastest way to start).
• The CrUX report (Chrome User Experience Report, data from real Chrome users, this is field data).
• Google Search Console (a separate Core Web Vitals report that groups URLs by good / needs improvement / poor and shows the problem across whole page types at once).

Field data vs. lab data

Field data comes from real users, on their own devices and connections. That's what counts toward your page assessment. Lab data is a single measurement under controlled conditions, good for diagnosis, because it instantly shows what to fix and you see the effect of a change right away. I combine the two: lab data to find the cause, field data to confirm the change actually reached customers. A new store with little traffic may not have field data yet, which leaves you with lab data. Measure the same URL several times, at different hours, because lab results fluctuate. Only a repeatable pattern tells the truth.

The most common performance bottlenecks in stores

The list of culprits is surprisingly repetitive, no matter the industry:

• Unoptimized product images (the most common bottleneck, files several times larger than their display size, hitting both LCP and CLS).
• No modern image formats.
• Too many third-party scripts (ads, analytics, chat, widgets, maps, all a risk to INP).
• A shifting layout.
• A heavy theme and too many plugins.

These are problems you can fix without rebuilding the whole store: compress and convert images, review your scripts, reserve space for elements.

Different platforms have their own typical weak spots. On self-hosted open-source setups (WooCommerce, PrestaShop, or Magento, for example) the server and plugin overload take the hit. On hosted SaaS platforms (Shopify, for example) you can't touch the engine, so you work with images, apps, and the scripts glued onto the template. Same mechanism, the mess just moves to a different place.

What performance has to do with conversion and Google rankings

Core Web Vitals connect sales and visibility. Sales: a slow, laggy, or jumpy page discourages the customer before checkout, and the cart gets abandoned. An unstable interface piles on quietly, with frustration building on every tap into a dead button. Visibility: Google uses Core Web Vitals as one of its signals. It's not a switch that lifts you to first place (content and relevance weigh more), but when two results are close, the better experience tips the balance. Technical fixes pay off faster than classic SEO, where you wait months for ranking movement. Performance isn't a one-time job, because every banner, plugin, and pixel makes the score worse. Treat Core Web Vitals as a parameter you check on a cycle, especially after a bigger change (a new template, a campaign with pixels, a fresh plugin).

Where to start

Remember the order. First, measure in PageSpeed Insights and Search Console. Figure out which metric is in the red, and only then go after the causes, starting with images and third-party scripts. The rest is cleanup, one thing at a time.

If you'd rather have someone do this for you, [I run these performance and compliance audits on live stores at Viromo](), where the score gets paired with a concrete fix list.

---

Author's note: I audit live online stores for performance, UX, and legal compliance. This article first appeared, in Polish, on the Viromo blog.