Core Web Vitals for ecommerce: what actually moves the needle
The three metrics Google measures, what counts as good, and the handful of fixes that produce most of the improvement on a real store.
BangkokSync4 min read
Site speed advice tends to arrive as a list of forty things. In practice, on most stores we look at, a small number of causes produce most of the problem — and they are usually the same ones.
Here is what Google actually measures, what the thresholds are, and where the real wins tend to be.
The three metrics, and what counts as good
Google's Core Web Vitals are three field metrics. A page is classified as good for a metric when at least 75% of real visits meet the threshold — which is why your own browser on office wifi is a poor test.
| Metric | Measures | Good |
|---|---|---|
| LCP — Largest Contentful Paint | How quickly the main content appears | 2.5 s or less |
| INP — Interaction to Next Paint | How quickly the page responds to interaction | under 200 ms |
| CLS — Cumulative Layout Shift | How much the layout jumps around | under 0.1 |
Note that INP replaced First Input Delay as a Core Web Vital. If you are working from an older checklist that still optimises for FID, it is out of date — INP is a considerably harder metric to satisfy, because it measures every interaction rather than only the first.
LCP: usually an image problem
On ecommerce pages the largest element is almost always the hero image or the first product photo. That makes LCP mostly an image-delivery question.
What tends to help most:
- Serve modern formats. WebP or AVIF instead of JPEG, at sensible dimensions. We routinely find product images being served at 2000px wide into a 600px slot.
- Do not lazy-load the hero. Lazy loading is good for everything below the fold and actively harmful for the thing LCP is measuring.
- Preload the hero image so the browser starts fetching it before it has finished parsing the page.
- Watch your fonts. A web font that blocks text rendering delays LCP when the
largest element is text.
font-display: swapand preloading the font file are the usual fixes.
INP: usually a JavaScript problem
INP measures the delay between someone interacting and the page visibly responding. Slow INP almost always means the main thread is busy.
The common causes on stores:
- Too many third-party scripts. Analytics, chat widgets, heatmaps, ad pixels, review widgets, A/B testing. Each is defensible on its own; collectively they are frequently the single biggest cause of a sluggish page.
- Heavy plugins and apps. On WooCommerce and Shopify alike, an app that adds a script to every page is paid for on every page, not just where it is used.
- Doing work on every interaction that could be done once, or done later.
The most effective thing we do here is usually an audit rather than a refactor: list every third-party script, find who asked for it, and remove the ones nobody can justify. It is unglamorous and it works.
CLS: usually a reserved-space problem
Layout shift happens when something loads and pushes content that was already there. It is the metric most likely to make a site feel cheap.
The fixes are mostly mechanical:
- Always set width and height on images so the browser reserves the space.
- Reserve space for banners and cookie notices rather than injecting them above existing content.
- Be careful with fonts. A fallback font with very different metrics causes a visible reflow when the web font arrives.
- Give ad and embed slots fixed dimensions.
Measure the right thing
Two distinctions worth being clear about, because they cause a lot of confusion:
Lab versus field data. Lighthouse in your browser is a lab test on your machine and your connection. Core Web Vitals as Google uses them are field data from real visits. A perfect Lighthouse score with poor field data is common and means your real users are having a worse time than your laptop is.
Your device versus your customers'. If most of your traffic is mid-range Android on mobile data — which, in Thailand, it very likely is — then testing on a recent iPhone on wifi tells you almost nothing useful. Throttle the connection and simulate a slower CPU.
Useful places to look at real data: the Core Web Vitals report in Google Search Console, and the field-data section of PageSpeed Insights.
Where speed actually pays
It is worth being honest about the business case. Speed is not a growth strategy on its own, and a fast site that is confusing will still not sell.
But slow pages compound with everything else. They cost you on mobile data, where a large share of Thai traffic lives. They make a good product feel less trustworthy. And they are a ranking input, which means a slow site is quietly paying more for the same traffic.
The practical order we work in: fix the images, cut the scripts nobody needs, reserve space so nothing jumps, then measure again with field data. That usually gets most of the available improvement before anything exotic is required.
Chat on LINE