Performance advice tends to arrive as a pile of vague virtues — "make it fast," "reduce JavaScript." Core Web Vitals are useful precisely because they're the opposite: three specific, measurable numbers that Google uses as a ranking signal and that map cleanly to how a page feels. Hit the thresholds and you've done most of the perceived-performance work that matters.
The set changed in March 2024, when Interaction to Next Paint (INP) graduated to a stable Core Web Vital and replaced First Input Delay (FID). If your mental model still has FID in it, this is the update. Here's each metric, what it measures, and what actually moves it.
The three metrics and their thresholds#
Google grades each metric into Good / Needs improvement / Poor, measured at the 75th percentile of real users — meaning three out of four visits should clear the "Good" bar.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP | Loading — when the largest content element renders | ≤ 2.5s | > 4.0s |
| INP | Interactivity — responsiveness to user input | ≤ 200ms | > 500ms |
| CLS | Visual stability — unexpected layout movement | ≤ 0.1 | > 0.25 |
The 75th-percentile detail matters: your fast laptop on office fiber is not the measurement. Field data from real devices and networks is, which is why lab tools and real-user numbers often disagree.
LCP — Largest Contentful Paint#
LCP marks when the biggest above-the-fold element — usually a hero image, a video poster, or a big block of text — finishes rendering. It's the closest single number to "when does the page look loaded?"
What actually moves it:
- Serve the LCP image well. Right-size it, use a modern format (AVIF/WebP), and don't lazy-load the above-the-fold hero — lazy-loading the thing that defines your LCP is a classic self-inflicted wound.
- Preload the critical resource. If the LCP element depends on a specific image or font, tell the browser early with a preload hint so it doesn't wait to discover it.
- Cut render-blocking work. Blocking CSS and synchronous scripts in the
<head>delay first paint. Inline the critical CSS, defer the rest. - Fix slow server response. A slow time-to-first-byte pushes everything back. Caching and a CDN do more here than any front-end trick.
INP — Interaction to Next Paint#
INP is the metric people understand least and feel most. It measures the latency of interactions — clicks, taps, key presses — from the moment the user acts to the moment the browser paints the visual response. Where the old FID only looked at the first interaction's input delay, INP considers interactions throughout the whole visit and reports (close to) the worst one. It's a much fairer proxy for "does this page feel sluggish?"
A bad INP almost always means the main thread is busy. The fixes are about giving the browser room to respond:
- Break up long tasks. A single 300ms JavaScript task blocks every interaction that lands during it. Split heavy work into smaller chunks and yield to the main thread between them.
- Do less on interaction. An expensive handler that re-renders half the page on every keystroke is the usual culprit. Debounce input, memoize the expensive parts, and defer non-urgent updates.
- Ship less JavaScript. Every kilobyte is parsed and executed on the main thread. Code-split, lazy-load below-the-fold widgets, and question whether that dependency needs to run on the client at all.
- Move heavy computation off the main thread. For genuinely expensive work, a Web Worker keeps the UI responsive.
CLS — Cumulative Layout Shift#
CLS scores how much visible content jumps around unexpectedly. The infuriating case: you go to tap a button, an ad or image loads above it, everything shifts down, and you tap the wrong thing. CLS quantifies that betrayal.
It's usually the easiest to fix because the causes are mechanical:
- Give images and video explicit dimensions (width/height or an aspect-ratio) so the browser reserves space before they load.
- Reserve space for anything injected late — ads, embeds, banners, cookie notices. A slot that collapses to zero and then expands is a guaranteed shift.
- Preload fonts and manage swapping so a font change doesn't reflow text.
- Avoid inserting content above existing content unless it's a direct response to user action.
How to measure honestly#
Two categories of tooling, and you need both:
- Lab data — Lighthouse, PageSpeed Insights, WebPageTest. Reproducible, great for debugging, but a simulated environment. Notably, INP and CLS depend on real interaction and time, so lab tools can only approximate them.
- Field data — the Chrome User Experience Report (CrUX) and the
web-vitalsJavaScript library capturing real sessions. This is what Google actually ranks on, so it's the number that counts.
The trap is optimizing the lab score to 100 while real users still suffer. Instrument real-user monitoring, watch the 75th percentile, and treat the lab as a debugger — not the scoreboard.
The takeaway#
Three numbers, three questions: does it look loaded fast (LCP), does it respond fast (INP), and does it stay still (CLS)? Chase the field data, not a perfect lab score, and fix causes in that order — a fast-painting page that ignores your taps still feels broken. Get all three into the green at the 75th percentile and you've delivered the performance that both users and search crawlers reward.
FAQ#
What replaced First Input Delay in Core Web Vitals?#
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a stable Core Web Vital in March 2024. INP is a broader measure of responsiveness: instead of only the first interaction's input delay, it evaluates interactions across the entire visit and reports close to the worst one.
What are the "good" thresholds for Core Web Vitals?#
At the 75th percentile of real users: Largest Contentful Paint (LCP) should be 2.5 seconds or less, Interaction to Next Paint (INP) 200 milliseconds or less, and Cumulative Layout Shift (CLS) 0.1 or less.
Do Core Web Vitals affect SEO?#
Yes. Core Web Vitals are part of Google's page experience signals and contribute to ranking. They're rarely the single deciding factor over content relevance, but among comparable pages, better vitals help — and they improve conversion and retention regardless of ranking.
Why do my lab scores look great but field data looks bad?#
Lab tools measure a single simulated load on controlled hardware, while field data reflects real devices, networks, and interactions at the 75th percentile. INP and CLS in particular depend on real user interaction over time, which a lab run can only approximate. Always trust field data for the metrics that Google ranks on.
References: