Google's three Core Web Vitals each measure a different piece of real user experience: LCP (how long the largest visible element takes to render), CLS (how much the page unexpectedly shifts around while loading), and INP (how responsive the page feels when someone actually interacts with it). All three came from research into what visitors notice and complain about, not arbitrary technical thresholds.
How to fix what it finds
A slow LCP is usually a large hero image or unoptimized web font blocking render — compress images, preload critical assets, and avoid render-blocking resources. Layout shift almost always traces back to images or ads without a reserved size, or content injected above what's already loaded. A weak INP usually means heavy JavaScript tying up the main thread when a visitor tries to click or type.
Google's pass/fail thresholds
Google scores each metric against three bands, measured at the 75th percentile of real page loads on mobile. A page needs to hit "Good" on all three to pass the Core Web Vitals assessment used in ranking signals — one metric in the "Poor" band is enough to fail it, even if the other two are fine.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
| INP (Interaction to Next Paint) | ≤ 200ms | 200ms – 500ms | > 500ms |
The lab result this tool runs is a single simulated visit, so it will rarely match the field thresholds exactly — a page can lab-test "Good" on LCP and still fail the field assessment if real visitors on slower connections or older phones consistently see it load slower.