You open your own store, it loads nicely, so it seems fine. The trouble is you have it in your browser cache and a fast phone, while the customer coming from an ad arrives for the first time, on a worse connection and often on older hardware. It is their experience Google counts - and it is their experience that decides whether they reach the cart.
Core Web Vitals are three specific measures of that experience. It is not about a general “fast or slow site”, but about three separate things: how fast the main content appears, how fast the page responds to a tap, and whether the layout jumps under a finger. Each one damages sales in a different way and each is fixed differently.
I break them down so it is clear what genuinely hurts in a WooCommerce store, how to check it and what to fix first to get the most for the least.
LCP - how fast the main content shows up
LCP (Largest Contentful Paint) measures how long it takes for the largest element on the first screen to appear - usually the hero image or the main product photo. That is the moment the customer feels “ok, the page has loaded”. Google wants you inside 2.5 seconds on a phone. Above 4 seconds you are firmly in the red zone.
In WooCommerce, LCP is usually broken by the same things:
- a heavy hero image or a banner uploaded straight from a designer, weighing several MB
- images in old JPG/PNG formats instead of WebP or AVIF
- a slow server that takes a long time to think before it even starts sending the page (TTFB, time to first byte)
- sliders and builders that load their own code first and only then show the image
The most frequent culprit is simply the biggest image at the top. If it weighs 3 MB and only loads after the builder’s scripts, your LCP is several seconds, however light the rest of the store is.
What helps: a hero image in WebP, compressed to a sensible weight and at the size it actually displays. Plus a fast first response from the server - decent hosting and caching. That is usually the single biggest jump on the meter.
INP - how fast the store responds to a tap
INP (Interaction to Next Paint) measures the delay between the customer clicking something - “add to cart”, a filter, opening the menu - and the page actually responding. This is the “I clicked and nothing happened, so I clicked again” kind of frustration. The target is under 200 milliseconds. Above half a second the customer feels the store stuttering.
INP is mainly broken by excess JavaScript working in the background. The browser has one lane for computation - if it happens to be chewing through plugin, builder and marketing scripts at the moment of the click, your click waits in the queue. WooCommerce adds its own quirk: by default a script refreshing the cart over AJAX (cart fragments) runs on every page, and it can weigh down interactions in places it is not needed at all.
This is the same family of problems I cover more broadly in the piece on why a WooCommerce store runs slowly - except here it is specifically about the response to a click, not about loading.
What helps: less code at startup - disabling plugins that genuinely add nothing, loading scripts conditionally only where they are needed, and limiting cart fragments to cart pages. Less JavaScript means a faster response.
CLS - whether the layout jumps under a finger
CLS (Cumulative Layout Shift) measures how much elements jump around during loading. Everyone knows the feeling: you go to tap “buy”, at the last moment a banner or an image loads and the button escapes downwards, so you tap something else. In a store that is not just irritation - it is clicks missing their target and abandoned purchases. Google wants a score under 0.1.
What causes shifts in WooCommerce:
- images with no dimensions specified - the browser does not know how much space to reserve, so content jumps when the image finally arrives
- fonts loaded late, swapping the text and shifting the layout
- banners, cookie bars and widgets loaded at the top of the page after the customer has started reading
- content injected by plugins and ads with no space reserved
CLS is sneaky, because on your fast connection images load instantly and nothing jumps. A customer on a slower network sees a completely different, jumping store.
What helps: specifying dimensions (width and height) for every image, reserving space for banners and widgets up front, and sensible font loading. This is often the cheapest fix of the three - the jumping simply stops once elements have their space assigned in advance.
How Core Web Vitals translate into sales and Google
Two things come together here. First, conversion: a slower and jumpier store loses customers along the way. According to Google’s own data the probability of a page being abandoned rises sharply with load time - going from 1 to 3 seconds is a clear jump. In e-commerce every one of those seconds means fewer carts, however good the offer is.
Second, search position. Core Web Vitals are one of Google’s ranking signals and - crucially - they count from the mobile version (mobile-first). Google grades your store as it looks on a phone, not on your monitor. That is why a store that runs beautifully on desktop can score badly exactly where Google is looking.
Core Web Vitals alone will not win a ranking in place of good content and a sensible offer - but weak scores genuinely drag you down, and the customer votes with their feet anyway. That is one reason why, when speeding up a WooCommerce store, I treat performance as part of the project rather than a “later” fix.
How to measure it - field versus lab
Start with PageSpeed Insights - paste in the address and you get all three values separately for phone and desktop. Look at the phone, because that is what Google counts. One thing confuses everybody: PSI shows two kinds of data and it is easy to draw the wrong conclusions.
- Field data - real users from the last 28 days, collected by Chrome. It shows how your store actually behaves for customers, on different phones and networks. That is the truth. It only appears once the store has enough traffic.
- Lab data - one test on a simulated device, run at that moment. Great for diagnosing “what specifically to fix”, because it gives a list of recommendations, but it is not the same as real customer experience.
The most common mistake is boasting about a good lab score while the field data says something completely different. If you have low traffic and no field data, fall back on a test from a phone over mobile data - that is closer to reality than a test on fast office Wi-Fi. How to work through a measurement like that step by step, and not fall into the “green score” trap, I set out separately in the speed mini audit.
What helps: always look at field data for mobile first. If it is not there - test on a real phone, not on your own laptop. Numbers from a laptop almost always lie in your favour.
What to fix first
The rule is simple: measure first, fix second, and start with what gives the biggest effect for the smallest cost. In practice my order looks like this:
- The hero image and the first screen - the fastest jump on LCP. WebP, sensible weight, correct dimensions. Often that step alone pulls LCP out of the red.
- A fast first response from the server - decent hosting plus a correctly configured cache. Without it, everything else starts late.
- Image dimensions and reserved space - a cheap, quick CLS fix that ends the jumping immediately.
- Slimming down JavaScript - fewer plugins, conditional script loading, limiting cart fragments. That improves INP, the response to clicks.
- Third-party scripts - chat widgets, pixels, maps, review widgets. Each adds load outside your control. Keep the ones that genuinely earn, cut the rest or load them late.
You do not have to do everything at once and you almost never have to build the store from scratch. In most cases weak Core Web Vitals are the sum of several of the above, not a “bad store”. Clearing them one by one usually moves the numbers from red to green with no loss of products, orders or Google positions.
Where to start on your side
If you do not know which of these numbers to aim at first - do not guess, send me a link. I will do a free review, measure your store’s Core Web Vitals on a phone and tell you plainly what is choking sales and what to fix first. You get the quote in writing within 24 hours, with no “starting from X”.
Frequently asked questions
What are Core Web Vitals in one sentence? Three measures of how a real user experiences a page: LCP (how fast the main content appears), INP (how fast the page responds to a click) and CLS (whether the layout jumps while loading). Google’s thresholds for good scores are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS - measured on the mobile version.
Do Core Web Vitals affect Google rankings? Yes, they are one of the ranking signals, but not the most important one. Good scores will not push weak content to the top; bad ones genuinely drag you down - and additionally cost you customers who drop off before the page settles. I treat them as hygiene, not as a ranking tactic.
Why does PageSpeed Insights show me a different score every time? Because a lab test is a single measurement on a simulated device and naturally fluctuates. Only the field data section, collected from real users over the last 28 days, is stable - and that is what to judge the store on. The lab score is for diagnosing what to fix, not for bragging.
Can Core Web Vitals be improved without rebuilding the store? In most cases, yes. Weak scores are usually the sum of a few things - a heavy image on the first screen, a slow server response, images with no dimensions, too many scripts - and each is fixed separately, without touching products, orders or page URLs.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.