Core Web Vitals: LCP, INP, and CLS
Concept
Core Web Vitals are the subset of Google's broader "web vitals" performance metrics elevated to a fixed, stable set used as both a UX quality bar and a Google Search ranking signal. There are currently three:
- LCP (Largest Contentful Paint) — time from navigation start until the largest visible content element (usually a hero image, a large block of text, or a background image) finishes rendering. Approximates "when does the page feel loaded" better than older metrics like
loador First Contentful Paint, which fire even when the main content a user actually came for hasn't appeared yet. Good: ≤2.5s. - INP (Interaction to Next Paint) — replaced First Input Delay (FID) as the official Core Web Vital in March 2024. Measures the latency of all interactions during a page visit (not just the first one) from user input to the next visual update, reporting roughly the worst observed interaction. Approximates "does the page feel responsive to clicks/taps/keypresses throughout the visit," not just on first load. Good: ≤200ms.
- CLS (Cumulative Layout Shift) — a unitless score summing unexpected layout shifts (elements moving after they've already rendered, typically from images/ads/fonts loading without reserved space) weighted by how much of the viewport moved and how far. Approximates "does content jump around while you're trying to read or tap it." Good: ≤0.1.
Each metric is scored against thresholds at the 75th percentile of real user visits — not lab data, not the average — measured via the Chrome User Experience Report (CrUX) using real Chrome traffic. This field-data requirement is deliberate: a page can look fast on a developer's fiber connection and fast in a synthetic Lighthouse run while still failing Core Web Vitals for real users on median mobile hardware and networks, and Google's ranking signal is based on the field data, not the lab score.
Tradeoffs
| Measurement approach | Benefit | Cost |
|---|---|---|
| Field data (CrUX, real user monitoring) | Reflects actual users' devices/networks/behavior; the source of truth for the Search ranking signal | Not available pre-launch (needs real traffic volume), can't be run in CI, and can't pinpoint which code change caused a regression without separate instrumentation |
| Lab data (Lighthouse, synthetic runs in CI) | Reproducible, can gate a PR before it ships, pinpoints exactly which change regressed a metric | Runs on one fixed device/network profile — a page can pass Lighthouse and still fail Core Web Vitals for the median real user on a slower device or network than the lab profile simulates |
| No measurement, "it feels fast to me" | Zero cost | No signal until Search ranking or user complaints surface a problem that may have existed for months, at a point where the responsible change is hard to identify |
The practical answer most teams converge on is both: lab data (Lighthouse in CI, or budgets enforced on PRs) to catch regressions before they ship, and field data (CrUX, or a real-user-monitoring tool sending actual web-vitals JS library measurements) as the metric that actually matters for ranking and real user experience — treating lab data as a leading indicator, not the target itself.
When to use / when not to
- Track all three on any public-facing page where Search ranking or perceived responsiveness matters — the highest-traffic, highest-value pages first (storefront/landing pages for LCP and CLS, any interaction-heavy page for INP) rather than trying to instrument everything at once.
- Prioritize LCP and CLS fixes on content-heavy, mostly-static pages (marketing pages, article pages) where the failure mode is almost always image/font loading and layout shift, not interaction latency.
- Prioritize INP on interaction-heavy pages (dashboards, forms, anything with client-side filtering/sorting) where a slow response to input is the more likely user-facing complaint than initial paint speed.
- Don't chase Lighthouse's 0-100 performance score as the goal itself — it's a weighted composite of several metrics (including but not limited to the three Core Web Vitals) using a lab device/network profile; a score change doesn't map linearly onto real Core Web Vitals field data, and optimizing the composite score can trade away a metric that matters more for one that's easier to move.
Common pitfall
Fixing the wrong element for LCP because the actual LCP candidate wasn't identified first — compressing an already-fast image while a slower-loading image or web-font-blocked text block elsewhere in the layout is the element the browser is actually scoring. Chrome DevTools' Performance panel and PageSpeed Insights both name the specific LCP element directly; skipping that identification step and guessing at "probably the hero image" wastes optimization effort on the wrong node. The equivalent CLS pitfall is fixing shifts caused by images without width/height attributes (or a CSS aspect-ratio) while missing shifts caused by web fonts swapping in (FOUT) or dynamically injected content (cookie banners, ads) pushing the page down after initial render — both need reserved space, not just images.
Engineering Lens
The metrics' design (75th percentile, real Chrome field data, three orthogonal dimensions instead of one composite score) reflects a deliberate choice to measure user-perceived experience rather than developer-perceived or lab-simulated experience — the gap between "fast on my machine" and "fast for the median real visitor" is exactly the gap Core Web Vitals exists to close. The transferable habit is the same diagnostic discipline that applies to any perceived-performance work: profile which specific element or interaction is actually being measured before optimizing, since intuition about "what's probably slow" is frequently wrong, and a fix aimed at the wrong node moves nothing on the metric that's actually failing.