Core Web Vitals
Core Web Vitals are Google's field-measured metrics for real user experience. Site Health captures them on every scan — both in the lab (Lighthouse) and from real users (CrUX).
The three Core Web Vitals
These are the three Google uses as ranking signals.
Largest Contentful Paint (LCP)
How long until the biggest thing above the fold actually renders. If LCP feels slow, the page feels slow.
| Rating | Threshold |
|---|---|
| Good | < 2.5s |
| Needs improvement | < 4.0s |
| Poor | ≥ 4.0s |
Biggest wins: compressed hero images, preloaded fonts, smaller JS bundles, caching.
Cumulative Layout Shift (CLS)
How much visible content jumps around while loading. Caused by images without dimensions, late-loading ads, and web fonts swapping.
| Rating | Threshold |
|---|---|
| Good | < 0.1 |
| Needs improvement | < 0.25 |
| Poor | ≥ 0.25 |
Interaction to Next Paint (INP)
The time between a user interaction (click, tap, keypress) and the next visual update. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 because it measures every interaction, not just the first.
| Rating | Threshold |
|---|---|
| Good | < 200ms |
| Needs improvement | < 500ms |
| Poor | ≥ 500ms |
Biggest wins: break up long tasks, defer non-critical JS, avoid heavy event handlers.
Supporting metrics
Not Core Web Vitals, but captured on every scan and often the first thing that moves when you optimize.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| First Contentful Paint (FCP) | < 1.8s | < 3.0s | ≥ 3.0s |
| Time to First Byte (TTFB) | < 800ms | < 1.8s | ≥ 1.8s |
| Total Blocking Time (TBT) | < 200ms | < 600ms | ≥ 600ms |
| Speed Index | < 3.4s | < 5.8s | ≥ 5.8s |
| Time to Interactive (TTI) | < 3.8s | < 7.3s | ≥ 7.3s |
Lab data vs. real-user data
Site Health surfaces both. They are not the same and both matter.
Lab data (Lighthouse) runs in a simulated environment — a specific CPU throttle, a specific network profile, one cold load. It's reproducible and great for catching regressions in CI. Every scan includes it.
Real-user data (Chrome UX Report, aka CrUX) is anonymized field data aggregated from Chrome users with usage reporting on. It reflects what your actual visitors experience — their devices, their networks, their flakey airport WiFi.
CrUX reports each metric at the 75th percentile of real user experience over the trailing 28 days. That means 75% of your visitors had an experience at least this good. Google uses this number for ranking and Search Console reports. Using an average would hide slow outliers; using the worst case would over-punish noise. 75th is the compromise.
When they disagree
| Lab | CrUX | What it means |
|---|---|---|
| Good | Poor | Lab conditions are kinder than reality — your users are on slower devices/networks than Lighthouse simulates. |
| Poor | Good | Your CMS template happens to lab-test badly, but real traffic lands on faster cached variants. |
| No CrUX | — | The page doesn't get enough Chrome traffic for Google to report field data. Lab is all you have. |
See the data in Site Health
- The per-page table on the site detail view shows lab CWV on every row.
- Expand a row to see CrUX values and opportunities.
- The page trends view charts LCP/CLS/INP across the last 20 scans per page.
- Alert rules and regression detection watch CWV thresholds for you.