How auditing works
Core Web Vitals
Three metrics that measure whether your page feels broken while it loads — and the ones Google ranks on.
The thresholds
A page must be “good” on all three to pass the assessment. Partial improvement changes nothing until every metric clears its threshold, which is why fixing the worst one first is the right order.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| CLS — Cumulative Layout Shift | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| INP — Interaction to Next Paint | ≤ 200ms | 200–500ms | > 500ms |
| TTFB — Time to First Byte | ≤ 800ms | 800–1800ms | > 1800ms |
TTFB is not one of the three ranking metrics, but it is a hard floor under LCP — no front-end work can make a page paint before the server has responded.
Field data versus lab data
This distinction is preserved throughout the report rather than flattened into one number, because presenting a simulation as a measurement would make the report confidently wrong about the thing you came to check.
| Source | What it is | Penalty applied |
|---|---|---|
crux | Real Chrome users over the last 28 days. What Google actually ranks on. | Full |
lab | A Lighthouse run on Google's hardware. Used when the page has too little traffic for CrUX. | 70% |
estimated | Modelled from our own request timing when PageSpeed Insights is unavailable. | 40% |
Fixing LCP
LCP marks the moment your main content becomes visible. Until then the visitor is looking at a page that appears broken. Work backwards from the element itself:
- Never lazy-load it. A lazy-loaded hero cannot start downloading until layout runs. This is the most common and costly misapplication of a good optimisation.
- Preload it with
<link rel="preload" as="image" fetchpriority="high">so the browser starts fetching during the initial parse instead of after it. - Serve modern formats. AVIF and WebP deliver the same visual quality at roughly half the bytes.
- Cut TTFB. Edge caching or static generation removes the floor entirely.
Fixing CLS
CLS is the metric behind tapping a button just as the page reflows and hitting an advert instead. Almost always one of four causes:
- Images without dimensions. Set
widthandheightto the real pixel size. CSS can still resize the image — the attributes only establish the aspect ratio so space is reserved. - Ads and embeds with no reserved space. Give the container a fixed min-height before the content loads.
- Content injected above existing content. A banner that appears at the top pushes everything down.
- Web fonts reflowing on swap. Preload the font and use
font-display: optional.
Fixing INP
INP measures the delay between a tap and the screen changing. It is what makes a site feel unresponsive even when it loaded quickly, and it is almost always main-thread contention:
- Break up long tasks. Yield with
scheduler.yield()inside heavy handlers so the browser can paint between chunks. - Move computation to a Web Worker where it does not compete with rendering.
- Defer third-party scripts that run on interaction. Analytics and chat widgets are the usual offenders.
Measuring it yourself
Add the web-vitals library — around 2KB, free — to collect field data from your own visitors rather than waiting for enough traffic to appear in CrUX. It is also the only way to see vitals segmented by page template, device or country, which is where the actionable detail lives.
Common questions
Why does my report say the vitals are estimated?
Because Google had no data for that URL. Field data comes from the Chrome User Experience Report, which needs enough real Chrome visitors to be statistically meaningful. Low-traffic and new pages fall back to a lab run, and if PageSpeed Insights is unavailable entirely we model the numbers from our own request timing. The report always states which source it used, and estimated figures carry a reduced penalty.
Why is there no INP score for my page?
INP measures the delay between a real person interacting and the screen updating. No lab tool can produce it, because there is no user to interact. It appears once your page has enough Chrome traffic for the CrUX dataset.
Do Core Web Vitals actually affect rankings?
Yes, but as a tiebreaker rather than a primary factor — relevance still dominates. The stronger argument for fixing them is commercial: they measure whether your page feels broken while loading, and that costs conversions whatever Google does with the number.