Core Web Vitals move when you fix the link in the chain that is actually broken, on the pages that carry money, as real visitors experience them. Below: what moves each metric, why lab and field disagree, what changed when we moved a UK store off WooCommerce, and a dated method for reading your own field data.
What the three metrics measure
Each one is a stopwatch on a different moment. LCP stops when the biggest thing in view has painted, and passes under 2.5 seconds. INP times the gap between a visitor’s tap and the screen answering it, and passes under 200 milliseconds. CLS adds up how far content jumps while someone reads, and passes under 0.1.
Two details matter more than the definitions. Google grades the visit at the three-quarter mark of your real traffic, so the slow quarter of phones decides it, not your office laptop. And the field figures are a rolling 28-day window, so a fix shipped today takes about a month to show in full.
What usually moves each metric
| Metric | Where the delay sits | Usual causes | Fixes that move it |
|---|---|---|---|
| LCP | A chain: server response, discovering the hero resource, downloading it, rendering it | Uncached pages; hero images set in CSS, injected by script or lazy-loaded; full-size images on phones; render-blocking CSS and scripts | Caching and a CDN; the hero in the HTML with a high fetch priority; right-sized images; less blocking code |
| INP | The main thread, busy when the visitor taps | Large bundles hydrating the whole page; third-party tags, chat widgets and recorders; heavy event handlers; very large DOMs | Code-splitting; deferring or removing third parties; breaking long tasks up; lighter handlers |
| CLS | Late arrivals pushing content that was already on screen | Images without dimensions; late banners and ad slots; web fonts that reflow text | Explicit dimensions; fixed containers for late content; metric-matched font fallbacks |
LCP’s links compound in order: nothing downstream starts until upstream finishes, which is why a slow server spends the whole budget before an image byte moves. INP failures are rarely one villain; a dozen scripts that each take “only” a hundred milliseconds is the usual finding. CLS is housekeeping, and it regresses the moment nobody owns it.
- 01Server responseFix: caching and a CDN for uncached pages
- 02Discovering the heroFix: the hero in the HTML, high fetch priority
- 03Downloading itFix: right-sized images, not full size on phones
- 04Rendering itFix: less render-blocking CSS and scripts
Lab says green, field says red: which to believe
Lab data (Lighthouse, the lower panel of PageSpeed Insights) is one simulated load on one throttled device with nobody using it. Field data is what Chrome collects from real visitors, published in the Chrome UX Report. Search uses the field figures. The lab is a diagnostic instrument, not the exam.
Green lab and red field usually means your real visitors have slower phones than the test, or the problem happens after load. INP is always the second case: a simulated load never taps anything. Red lab and green field is common for desktop-heavy B2B traffic.
Diagnose in the lab, verify in the field, and let the field decide whether there is a problem worth paying for.
What a platform move changed for FleaSolve
Sometimes the platform is the culprit. FleaSolve, a UK maker of vet-grade flea and tick treatment, ran its direct-to-consumer store on WooCommerce. Speed, scalability and upkeep were constrained by the setup and its plugins. We migrated the store to a Shopify 2.0-compatible theme customised for the brand, designed mobile-first rather than adapted from desktop.
The FleaSolve case study records the outcome as improved performance and page-load speed across devices, increased mobile engagement, and less operational overhead from removing WooCommerce plugin dependencies. It records no before-and-after field figures, so we quote none here. Its public field data today is open to anyone, using the method below.
The lesson for your own store: when the fixes in the table keep being undone by the theme or the plugin stack, patching costs more over a year than performance work on the layer underneath. When to migrate your eCommerce platform covers that decision.
A method for reading your own field data
- Put the URL into PageSpeed Insights with the mobile tab selected. Read only the top panel, “Discover what your real users are experiencing”. If it says there is not enough data for the page, read the origin figures instead and note that you did.
- Record the date, the URL, mobile or desktop, page or origin, and the 75th-percentile value and rating for LCP, INP and CLS.
- Repeat for each template that carries money: home, category, product, checkout entry, and your main paid landing page.
- After a fix ships, wait the full 28 days before the comparison reading. Readings inside the window mix old visits with new.
- Report the two readings side by side with their dates, and say what else changed between them. A campaign, a sale or a new market changes the visitors, and the visitors change the figures.
| Date read | URL or origin | Device | LCP p75 | INP p75 | CLS p75 | What changed since the last reading |
|---|---|---|---|---|---|---|
| Before the fix | Mobile | |||||
| 28 days after | Mobile |
When performance work is not the answer
It pays when a commercial page fails a threshold in the field: product, category, checkout and paid landing pages, where every visitor is bought or close to buying. Moving LCP from four seconds to 2.4 crosses a line; moving it from 1.8 to 1.2 mostly buys bragging rights.
It pays least when the field figures are already green and the real problem is a page nobody wants to read or link to. Speed cannot rescue that. Rank speed against the other gaps before spending on it.
