Understanding Core Web Vitals
Three numbers Google ranks you on.
What LCP, INP and CLS actually measure, the targets that count, and where a quick simulator can — and can't — tell you what's wrong.
LCP — Largest Contentful Paint.
The time from navigation start to when the largest above-the-fold element is painted — usually the hero image or the main headline. Good is under 2.5 seconds; poor is over 4. The culprit is almost always slow images: oversized hero photos loaded without responsive sizes, fonts blocking text render, or render-blocking JavaScript that delays paint. The fix: serve appropriately-sized images, preload the LCP candidate, eliminate render-blocking resources.
INP — Interaction to Next Paint.
Replaced FID (First Input Delay) in March 2024. INP measures the responsiveness of every interaction across the page's lifetime, not just the first. Good is under 200 ms; poor is over 500. The cause is long-running JavaScript on the main thread: a heavy event handler, hydration of a too-large component tree, an analytics call that synchronously serialises a large object. Defer non-critical work, break long tasks into chunks, hydrate islands rather than the whole page.
CLS — Cumulative Layout Shift.
The total of how much content shifts unexpectedly during the page's lifetime. Good is under 0.1; poor is over 0.25. Caused by images without explicit width/height attributes, web fonts swapping in with a different metric, late-loaded ads pushing content around. The fix is reserving space: width and height on every image, aspect-ratio on responsive containers, font-display strategies that minimise FOUT.
A worked diagnostic.
A page reports LCP 4.2s, INP 320ms, CLS 0.18. Three problems, three diagnoses. LCP is bad because the hero image is 2.4MB JPEG served unsized; serve a 320KB AVIF with width/height attrs. INP is bad because a chat-widget script blocks for 280ms on first interaction; defer it with <script async defer>. CLS is bad because a banner ad loads 500ms into the page and pushes the article down; reserve a fixed slot with min-height.
Three numbers, three fixes
LCP 4.2 / INP 320 / CLS 0.18
Each metric points at a different category of work.
LCP → image work ; INP → JS work ; CLS → layout work
= Targeted remedies
Lab vs field data.
Lighthouse runs as a lab tool — a fresh browser session on a throttled connection, deterministic per run but not representative of real users. CrUX (Chrome User Experience Report) is field data — actual visits from real users on real connections, the basis of Google's Core Web Vitals ranking. They often disagree; lab data is a development tool, field data is the truth. Optimise for the intersection.
What a simulator can't do.
A quick simulator can warn about predictable issues — page weight too large, fonts render-blocking, images without dimensions — by parsing the markup. It can't run your JavaScript in a real browser, so it can't catch INP regressions caused by a heavy hydration step or measure real LCP on a specific device profile. For launch-time validation, run a real Lighthouse or PageSpeed audit; the simulator is a faster pre-flight check.