Core Web Vitals, decoded
Core Web Vitals are the three user-experience metrics Google treats as a ranking signal, plus a couple of supporting ones you will see in any dossier. Here is what each measures, the threshold for a passing grade, and how to fix it.
The thresholds at a glance
| Metric | Measures | FAST (good) | SLOW (poor) |
|---|---|---|---|
| LCP | Loading — largest element paints | ≤ 2.5 s | > 4.0 s |
| INP | Responsiveness — interaction latency | ≤ 200 ms | > 500 ms |
| CLS | Visual stability — layout shift | ≤ 0.10 | > 0.25 |
| FCP | First content paints | ≤ 1.8 s | > 3.0 s |
| TTFB | Server responds | ≤ 0.8 s | > 1.8 s |
The band between FAST and SLOW is AVERAGE / "needs improvement". Site Inspector maps FAST → PASS, AVERAGE → WARN, SLOW → CRITICAL.
LCP — Largest Contentful Paint
The time until the biggest above-the-fold element (usually a hero image, heading or banner) is rendered. It is the headline "is it fast?" metric.
How to pass
- Cut server response time (TTFB) — fast hosting and caching first.
- Preload the LCP image and serve it in a modern format (AVIF/WebP) at the right size.
- Remove render-blocking CSS/JS in the critical path.
- Use a CDN so bytes start arriving sooner for distant visitors.
INP — Interaction to Next Paint
Replaced First Input Delay in 2024. It measures how quickly the page visually responds to taps, clicks and key presses across the whole visit — a real-world responsiveness score.
How to pass
- Ship less JavaScript; break long tasks into smaller chunks.
- Defer non-critical work and third-party scripts.
- Avoid heavy work in event handlers; yield to the main thread.
CLS — Cumulative Layout Shift
How much the page jumps around as it loads — the unitless score of unexpected layout shifts.
How to pass
- Always set explicit
width/height(oraspect-ratio) on images and embeds. - Reserve space for ads, banners and late-loading content.
- Preload web fonts and use
font-displaywisely to avoid reflow.
FCP & TTFB — the supporting cast
FCP is when the user first sees anything render — a good early signal that something is happening. TTFB is how long the server takes to send the first byte; it sits underneath everything else, so a slow TTFB drags down FCP and LCP together. Both are the first things to look at when LCP is poor.
Lab vs field — which number is "real"?
Google ranks on field data (real Chrome users, the CrUX panel in your dossier), not the lab Lighthouse run. Use lab numbers to diagnose and iterate quickly; judge success by the field data. If your origin has too little traffic for field data, optimise toward the lab thresholds above and they will translate.
Run a scan to see your own LCP, INP, CLS and FCP, then come back here to fix the red ones.