Fast is a feeling.Measure it anyway.

The browser measures itself. The SDK listens with the platform’s own PerformanceObserver, accumulates layout shift with the standard session-windows rule, estimates INP the way the metric is defined, and sends one compact event per page load, when the page is first hidden. A metric that never happened is omitted rather than zeroed: a visit with no interaction reports no INP at all.

Each visit is rated against Google’s published thresholds, and the dashboard reports the p75, the same statistic Google’s field tooling reports, so your numbers and Search Console argue about the same quantity.

The capture rides in the same 1.9 KB extras file as click and scroll tracking, loaded from your own instance once you switch it on. No third-party performance service sees your traffic, and no measurement library is added to your bundle.

Three layers. Five p75 cards, one per metric, each with the split of good, needs-improvement and poor visits behind it. A daily p75 trend, which is where a regression shows up the day a deploy causes it. And a per-page table, slowest LCP first, with each page’s p75 LCP, INP and CLS set beside how many loads it carries, so the effort goes where the traffic is.

That last column is the point. A slow page with real traffic outranks a slower page nobody visits, and the table keeps both facts in the same line of sight.

Yes, for what it is for. Lighthouse and similar lab tools run one synthetic load on one simulated device, which is exactly what you want while fixing a page and watching a number move. Field data answers the other question: what the fleet of real visitors, on real devices and networks, actually experienced. The two disagree routinely, and both are right.

Field numbers also need traffic to be stable. On a page with a handful of loads a day, the p75 will wander; read the trend rather than a single day, and trust the busy pages first.