Core Web Vitals Cheat Sheet: Every Metric, Threshold, and Acronym on One Page
Core Web Vitals documentation is scattered across a dozen Google properties, half of it refers to metrics that no longer exist, and every tool uses a different acronym for the same idea. This is the reference we wished existed: every metric, every threshold, every acronym, one page. Bookmark it; the numbers below are the current, post-INP thresholds.
The Three Core Web Vitals
These are the only three metrics in Google's page experience ranking signal. All are measured from real Chrome users (field data), evaluated at the 75th percentile, mobile and desktop separately.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading speed | ≤ 2.5 s | 2.5–4 s | > 4 s |
| INP | Responsiveness | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | Visual stability | ≤ 0.1 | 0.1–0.25 | > 0.25 |
LCP, Largest Contentful Paint
The time from navigation until the largest visible element (usually a hero image or headline block) finishes rendering. A good LCP is 2.5 seconds or less. Typical causes of failure: slow server response (TTFB), render-blocking CSS/JS, and hero images that aren't prioritised (missing fetchpriority="high", lazy-loaded above the fold).
INP, Interaction to Next Paint
How quickly the page visually responds when a user clicks, taps, or presses a key, measured across all interactions, reporting one of the slowest. A good INP is 200 milliseconds or less. It replaced FID in March 2024 and is now the most-failed vital. Main cause: JavaScript blocking the main thread, very often third-party scripts, chat widgets, GTM tags, consent banners. Note: INP cannot be measured in lab tests, only real users generate interactions.
CLS, Cumulative Layout Shift
How much visible content unexpectedly moves during the entire page session, scored as impact fraction × distance fraction (unitless). A good CLS is 0.1 or less. Main causes: ads injected without reserved space, images without width/height attributes, web fonts swapping late, and banners pushing content down.
Supporting Metrics (Diagnostic, Not Ranking Signals)
These appear in reports and influence the Lighthouse score, but Google's ranking signal only reads the three above.
| Metric | Stands for | What it tells you | Good (guideline) |
|---|---|---|---|
| TTFB | Time to First Byte | Server/CDN response speed; the floor under your LCP | ≤ 0.8 s |
| FCP | First Contentful Paint | When anything first renders | ≤ 1.8 s |
| TBT | Total Blocking Time | Main-thread blockage during load; the lab proxy for INP | ≤ 200 ms |
| SI | Speed Index | How quickly content visually fills the viewport (lab only) | ≤ 3.4 s |
A useful chain to remember: TTFB caps FCP, FCP caps LCP. If TTFB is 2 seconds, no amount of image optimisation gets LCP under 2.5.
Retired Metrics (Ignore Any Guide Still Citing These)
| Metric | Was | Status |
|---|---|---|
| FID (First Input Delay) | The old responsiveness vital (≤ 100 ms) | Replaced by INP in March 2024. Any article leading with FID is outdated |
| TTI (Time to Interactive) | Lab loading metric | Removed from Lighthouse (v10). Historical only |
The Acronyms Around the Metrics
CrUX, Chrome User Experience Report. Google's dataset of real Chrome users' performance on your site. The source of truth: the ranking signal, the PageSpeed Insights assessment, and Search Console's report all read it. Rolling 28-day window, updated daily, which is why fixes take up to 28 days to show.
Field data vs lab data. Field = measurements from real visitors (CrUX, RUM). Lab = a synthetic test on simulated hardware (Lighthouse). They routinely disagree, and only field data affects rankings.
p75, 75th percentile. The pass bar: at least 75% of real visits must hit the "good" threshold. Your median user being fast isn't enough; the metric is set by your slower quartile.
PSI, PageSpeed Insights. The report at pagespeed.web.dev showing CrUX field data (top) and a Lighthouse lab run (bottom) for one URL. The 0–100 score is lab-only and not a ranking factor.
Lighthouse. The open-source lab engine behind the PSI score, DevTools audits, and most "site speed graders". Current score weighting: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%.
RUM, Real User Monitoring. Your own field data: a small script (e.g. the free web-vitals library, ~2 KB) reporting every real visit to your analytics. The only way to verify fixes in days instead of waiting out the CrUX window, and the only field data available for low-traffic pages.
GSC, Google Search Console (Core Web Vitals report). CrUX data grouped by URL pattern, so you can see which templates fail rather than testing pages one at a time. The right starting point for any CWV project.
Origin vs URL-level data. CrUX reports per-URL when a page has enough traffic; otherwise tools silently fall back to the whole-domain ("origin") aggregate. Check the label before drawing conclusions about a specific page.
Long task. Any main-thread task over 50 ms, the building block of poor INP. The LoAF API (Long Animation Frames) is the newer diagnostic for attributing them to specific scripts.
LCP sub-parts. Diagnostic breakdown of LCP: TTFB → resource load delay → resource load time → render delay. Tells you whether to fix the server, the image, or the render path.
Which Tool for Which Job
| Task | Tool |
|---|---|
| Find which templates fail, site-wide | Search Console CWV report |
| Check one URL's field + lab data | PageSpeed Insights |
| Diagnose why a metric fails | Chrome DevTools Performance panel / Lighthouse |
| Verify a fix within days | RUM (web-vitals library → your analytics) |
| Trend data over time | CrUX History API (weekly) / CrUX Dashboard |
Frequently Asked Questions
What is a good Core Web Vitals score?
Passing means all three metrics hit "good" at the 75th percentile of real visits: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. There's no combined score, a page passes or fails each metric individually.
Is the PageSpeed Insights score part of Core Web Vitals?
No. The 0–100 score is a Lighthouse lab simulation and isn't used in ranking. The pass/fail Core Web Vitals assessment above it, built on CrUX field data, is the part that matters.
Do Core Web Vitals differ for mobile and desktop?
The thresholds are identical, but Google evaluates the datasets separately, and mobile is where most failures live: slower devices, slower networks. A site can pass on desktop and fail on mobile, rankings on each device class follow the matching dataset.
The Cheat Sheet Is the Map. Need the Territory Fixed?
A site failing across thousands of URLs needs fixing at the template level. That's our core service.
LinkedIn