Core Web Vitals (CWV) are the three metrics Google uses to represent real user experience, and they are a confirmed if modest ranking signal. They measure three different feelings a visitor has: how fast the main content loads, how quickly the page responds, and how steady it stays while loading.
The three metrics
| Vital | Measures | Good threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | Loading, when the biggest content paints | ≤ 2.5 s |
| INP (Interaction to Next Paint) | Responsiveness, how fast taps and clicks answer | ≤ 200 ms |
| CLS (Cumulative Layout Shift) | Visual stability, how much layout jumps | ≤ 0.10 |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
Field data, and what a lab tool can honestly say about it
Core Web Vitals are officially measured from field data: real Chrome users, reported through the Chrome User Experience Report at the 75th percentile. A page passes only when all three vitals are in the good range for enough real visits.
Everything on this site is a lab measurement, and the three vitals survive that translation very differently. It is worth being precise about which:
- LCP translates well. A lab run genuinely watches the largest element paint, and the
causes it finds, a late hero or a blocked
<head>, are the same ones real visitors meet. - CLS translates badly, in a way that hides defects. A lab run never scrolls. Of the 162 sites we parsed, 86 ship images with no dimensions, and 82 of those 86 still score “good” on lab CLS, because the shift happens during a scroll that never occurs.
- INP does not translate at all. It needs a real interaction, and a lab run performs none. Lighthouse substitutes TBT; we report TBT and do not present it as an INP figure.
Why they matter
- A direct ranking signal, and a tie-breaker in competitive results.
- They correlate with bounce and conversion: slow, jumpy pages lose visitors before they convert.
- They are visible to anyone. A poor CWV badge shows up in Search Console and in third-party tools your competitors can read too.
What breaks each one
- A late hero image or render-blocking
<head>delays the largest paint, which is LCP. - Heavy main-thread JavaScript, from big third-party bundles and un-deferred scripts, keeps the page from answering taps, wrecking INP.
- Unsized images and content injected after load, including ads, banners and fonts swapping in, push the layout around and drive up CLS.
They pull against each other
- Preloading the LCP hero at high priority competes with the text and CSS behind FCP, and adds bytes that can work against LCP itself on slow connections.
- Deferring JavaScript to protect INP delays LCP when the hero is drawn by that same script.
- Reserving space to hold CLS steady is the cheap one, and rarely costs the others.
This is why fixing vitals one at a time turns into whack-a-mole, and why our pipeline tunes all three in a single pass rather than optimising each in turn.
How WebSpeed improves them
WebSpeed works all three at once from a single proxy pass: it preloads the real LCP image and inlines critical CSS for LCP, defers third-party and non-critical scripts to clear the main thread for INP, and writes real image aspect-ratios into the markup to reserve space for CLS, without touching the source site.