Glossary
Real user monitoring
Real user monitoring collects measurements from the browsers of actual visitors and reports them in aggregate. Because it observes rather than controls, its output is a distribution across every device, network and cache state your audience really has — not a single figure. That makes it the only honest answer to whether a site is fast for the people using it, and a poor tool for working out why, since nothing about it can be re-run with one variable changed.
Why the result is a distribution
Every visitor measures under their own conditions, so the data is a spread rather than a value.
An average hides the tail, and the tail is where the people who leave are. A slow experience for a tenth of visitors is invisible in a mean.
Which is why field measurement is conventionally reported at a high percentile: it describes what a bad visit looks like rather than a typical one.
A site whose median is excellent and whose high percentile is poor has a real problem affecting real people, and only the percentile shows it.
What it collects
Rendering measurements — when the largest element painted, how much the layout shifted, how long interactions took to respond.
Navigation timing: name resolution, connection, first byte, load.
Context: device class, connection type, page, country, so the distribution can be segmented.
It requires traffic. A page with few visits produces no usable distribution, which is where synthetic measurement remains the only option.
Why it cannot tell you the cause
It reports that a page was slow for a segment of visitors. It does not report what on that page was responsible.
You cannot re-run a real visit with one script removed, which is the operation that isolates a cause.
Segmentation narrows it — a device class, a country, a page — and narrowing is not the same as identifying.
So the useful sequence is: field data says where to look, a controlled run says what to change, field data says whether it worked.
What it means for an external scan
An external scan cannot produce field data. It has one visitor, and that visitor is the scanner.
What it can do is find the structural causes field data would be pointing at: a blocking resource, an oversized image, a lazy-loaded hero.
Which is why a performance finding here is phrased as a cause rather than as a score to beat.
The privacy consideration is real and belongs in the same conversation: field measurement collects data from visitors, which is a processing activity to declare.
Segmenting the distribution
By page template, since one slow template can drag a whole site percentile without any individual page being reported.
By device class, which is usually where the tail lives.
By country and network, which separates a site problem from a delivery problem.
By whether the visit was a first view or a repeat, since a cache makes the two barely comparable.
Frequently asked questions
- Why report a high percentile instead of an average?
- Because an average hides the tail, and the tail is the visits that fail. A percentile describes what a bad visit looks like, which is the one worth fixing.
- Can field data tell me what to fix?
- It tells you where and for whom, not what. Isolating a cause needs a controlled run where one variable changes, which real visits by definition are not.
- Does collecting it have privacy implications?
- Yes. It gathers data from visitors' browsers, which is a processing activity like any other and belongs in your privacy documentation and your consent design.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website