Skip to content
DocsGo to Dashboard
Monitor real users with RUM

Four metric cards, a Core Web Vitals distribution, a field budget verdict, and seven coarse breakdowns — all built from consented samples

Core Web Vitals distribution and field performance budget panels on the real-user report
Counts, not averages: `good`, `needs improvement`, and `poor` per metric, with the 75-sample budget floor underneath.

The report is built from consented samples only, and it is deliberately aggregate: percentiles, distributions, and coarse segments, with nothing that identifies a visitor or a page.

1. Read the metric cards#

Four cards cover Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and Time to First Byte. Each shows four rows in order: Field p50, Field p75, Field p95, and Latest lab — the last annotated with the lab run's strategy when one exists. Milliseconds are rounded, CLS is shown to three decimals as a score, and a metric with no samples in the window reads Not available rather than zero. Read p75 as the decision figure and p95 as the tail your slowest visitors experience.

2. Read the distribution#

The Core Web Vitals distribution panel gives counts rather than averages for the displayed period: for each metric, how many samples were good, how many needs improvement, and how many poor against the published thresholds. A healthy p75 can still hide a long poor tail, and this panel is where you see it.

3. Read the field budget verdict#

The next panel is headed Field performance budget: followed by the status, and its sub-line states the rule plainly: Budgets evaluate sustained p75 results only after 75 samples per metric. Until a metric reaches 75 samples its line reads as a fraction of that floor instead of a verdict, and the overall status stays Collecting evidence. The per-metric labels in this panel are the short forms LCP, INP, CLS, and TTFB.

4. Read the breakdowns#

Seven breakdowns slice the same samples: Device, Page group, Coarse region, Network, Referrer category, Release, and Configuration. Each lists up to six rows with a sample count and that row's LCP p75 in milliseconds, and shows Waiting for samples while a dimension has no data. These are coarse buckets on purpose — a region, a network class, a referrer category — not countries, paths, or raw referrers.

5. Read the footnote#

The footnote closes the evidence chain: the total number of consented field samples, the Configuration v{n} those samples belong to, a Freshness state that reads fresh when the newest retained sample is at most fifteen minutes old and stale once it is older, and the privacy statement — no URLs, paths, raw referrers, country codes, IP addresses, user agents, or user or session identifiers stored. When a window holds more samples than the report analyses, a notice tells you the percentile uses the latest analysed subset.

Expected result#

You can quote a sustained p75 per metric, describe the tail and the distribution behind it, and name the device class, page group, release, or configuration version responsible.

Do not treat the lab column as a field result. Latest lab is a controlled single run on one profile, while the field rows are what real visitors measured. Where the two disagree, that disagreement is the finding — pair it with Run a Lighthouse audit before deciding what to change.

Back to Monitor real users with RUM