Understanding scores
Three metrics, one percentile, and one rule about which source is allowed to give you a verdict.
The three metrics
LCP — largest contentful paint. How long until the biggest thing on screen finished drawing, usually your hero image or headline. It answers: did the page look ready?
INP — interaction to next paint. The worst delay between someone tapping and the screen changing, across the whole visit. It answers: did the page feel alive?
CLS — cumulative layout shift. How much the page moved under the reader after it started drawing. It answers: did anything jump while they were trying to tap it?
Where the boundaries sit
These are Google’s numbers, applied identically to field and lab values through one shared function — so a reading never changes meaning depending on which screen shows it.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 – 4.0 s | > 4.0 s |
| INP | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | ≤ 0.10 | 0.10 – 0.25 | > 0.25 |
| FCP | ≤ 1.8 s | 1.8 – 3.0 s | > 3.0 s |
| TTFB | ≤ 800 ms | 0.8 – 1.8 s | > 1.8 s |
Only the first three are Core Web Vitals. FCP and TTFB are diagnostic: they explain why LCP is what it is, and they do not decide whether you pass.
Why the 75th percentile
A page is scored on the experience of its unluckiest quarter of visitors, not its average one.
Averages hide the phone on a train; p75 does not. If your p75 LCP is 2.4 seconds, three out of
four visits finished painting inside that.
This is why teams pass their own testing and still field complaints. Optimising for the median visit means optimising for a laptop on office wifi — and the quarter you are actually scored on is somewhere else entirely, on a mid-range Android over cellular.
It also means you pass or fail per metric, not on an average of them. Three good scores and one poor one is a failing page; there is no partial credit.
When field and lab disagree
This is the most common source of confusion, and the disagreement is usually informative rather than a fault.
| Pattern | Usually means |
|---|---|
| Lab good, field poor | Real devices are slower than the simulation, or your visitors are on worse networks. Often third-party scripts that the lab run does not trigger. Trust the field. |
| Lab poor, field good | Lab throttling is harsher than your actual audience, or your traffic is desktop-heavy. Treat lab failures as lower priority. |
| Lab moved, field did not | Normal. Field is a 28-day rolling window — give it a week to start moving and four to settle. |
| Lab has INP, field does not | Lighthouse cannot measure INP; it needs a real interaction. Total Blocking Time is the lab stand-in. |
When your URL has no field data
CrUX only reports a page once it has seen enough Chrome traffic, which most pages below the home page never reach. Rather than leave you with nothing, VitalLens fetches URL-level data first and fills the gaps from the origin, metric by metric:
- URL first — LCP and CLS. Paint and layout are specific to the page you are looking at, and should not be smoothed out by the rest of the site.
- Origin — INP, FCP and TTFB. Server and interaction timings are steadier and better sampled across the whole origin.
Every report says which it used — url, origin or hybrid
— so you always know how close to your page the number really is. An origin-level LCP tells you
something about your site; it does not tell you much about this page.
What the verdict means
The executive verdict summarises field performance only. “Excellent” means every Core Web Vital passes for real users and the lab run shows no systemic bottleneck; remaining lab opportunities are still listed, just de-emphasised once real users are fine.
If no field data exists for your URL or its origin, the verdict is withheld entirely rather than inferred from the lab score. A page can show a lab score of 100 and still carry no verdict — that is working as intended, not a bug.
The verdict needs field data. Full stop.
If nothing real is available for your URL or your origin, we withhold the verdict instead of inferring one from the lab run. You still get the whole Lighthouse diagnosis — it just does not get to call the result.