Skip to main content
Narrative measures how fast your site is for real people, not for a lab. The numbers come from the Chrome User Experience Report (CrUX), Google’s public dataset of what Chrome users actually experienced on your pages over the trailing 28 days. It is the same field data Google reads when it assesses your Core Web Vitals, so what you see in Narrative lines up with what Google holds against you.

​
Why field data and not Lighthouse

Lighthouse simulates one load on one synthetic device. CrUX aggregates millions of real loads on real connections. Two things follow:
  • It is what Google measures. Google’s ranking signal is field data, not a lab score, so a Lighthouse number can be green while the signal is red.
  • It scales. A Lighthouse run per page is minutes of work per page and half an hour on a site of any size. CrUX answers in one request.
The trade is coverage. CrUX only reports a page once enough Chrome users have loaded it. Most pages on most sites never reach that bar, and that is normal. Narrative is careful to say no data rather than guessing.

​
What is fetched

On every crawl, Narrative asks CrUX for:
  1. The origin. Your site as a whole. This is almost always available and is the number to watch.
  2. Up to 50 pages, chosen by link score, so the pages that carry the most internal authority are the ones measured. Pages with too little traffic for CrUX come back as no data and are left blank, never filled in.
A quota problem, an outage or an authentication failure is recorded as not measured, which is different from no data. Collapsing the two would make a quota error look like a fast site, which is the worst possible reading.

​
The four numbers

All four are reported at the 75th percentile, which is Google’s convention: three in four visits were at least this good. Thresholds are Google’s published boundaries. Narrative stores the percentile rather than the band, so when Google moves a boundary, as it did when INP replaced FID in 2024, history stays readable.

​
What moves the verdict

The Core Web Vitals check in the audit library judges on Google’s own three: LCP, INP and CLS. The line is drawn where Google draws it, so Narrative and Search Console never disagree about the same number:
  • Every metric inside its Good boundary: pass.
  • Any metric in the needs-improvement band: warn, naming the metric and its target.
  • Any metric over its Poor boundary: fail.
A page CrUX has no LCP or CLS for is not judged at all. A missing measurement is not a fast page. Each finding carries one line of advice per metric that is over target, because each has a different cause and usually a different owner: TTFB is the server (caching, a slow origin, or a redirect before the document), LCP is usually the hero image or a blocking font, INP is main-thread work from a script running while someone tries to tap, and CLS is layout.
TTFB is marked experimental in CrUX and is not a Core Web Vital. Narrative reports it and advises on it but never fails a site on TTFB alone, following Google’s own guidance that it matters when it is dragging one of the other three.

​
Where to see it

  • Analyze → Site vitals: the origin’s four numbers and their trend across crawls.
  • Site Health: each measured page’s speed in its row, beside what it served and what is wrong with it.
  • Repairs: a Performance repair lists the pages whose LCP is over target, with the steps that usually fix it.