Every real visitor's browser records exactly how loading went — timing for every phase, every resource, every paint. Real-user monitoring collects those records, which makes your users the largest and most honest test fleet you will ever have: every device, every network, every geography, weighted precisely by how much they matter to you. The craft is in collecting it without harming pages, and in tagging it so it can answer the questions you'll actually ask.
Why field data outranks everything
Synthetic tests measure what a robot in a data centre experiences; RUM measures what your revenue experiences. The two disagree constantly, and when they do, RUM is right about users and synthetics are right about regressions — keep both, but settle experience arguments with field data (the synthetic guide covers the other half). RUM is also the only place certain truths live: real cache-hit experience across a session, real protocol adoption, real performance on networks no test agent sits on. If you optimize delivery for users on far networks, RUM is the only instrument that can even see them.
Shipping the beacon safely
A RUM agent is JavaScript that reads the browser's timing interfaces (Navigation Timing, Resource Timing, the paint and layout observers) and posts a small beacon home. The prime directive: the measurement must not damage the thing measured. Load the agent async or deferred, never render-blocking; send data with sendBeacon or fetch-with-keepalive so unload isn't delayed; keep the payload small. Decide the send moment deliberately — beacon on page-hide rather than on load, or metrics that settle late (layout shift, interaction latency) go missing. And treat the beacon endpoint as production infrastructure: it takes a request per sampled page view, it should sit behind your CDN, and its failure mode must be silent. A vendor product handles most of this for you; the checklist still applies when evaluating one.
Sampling: how much is enough
You rarely need every page view. Sampling saves beacon traffic and vendor fees, and statistically you lose little: for a site with millions of views, a 10% sample estimates a p75 almost as tightly as the full firehose. The rules that keep samples honest: decide per-session rather than per-view (so journeys stay intact), keep the rate stable (a rate that changes mid-quarter silently breaks every trend line), and floor it by segment — 10% of Germany is plenty, but 10% of your small-but-strategic New Zealand traffic may be too thin to read percentiles from, so sample small segments at a higher rate and record the rate in the beacon so it can be reweighted. When in doubt at moderate traffic, start at 100% and dial down when volume or invoices demand it.
The dimensions that matter
Undimensioned RUM produces one sad chart — "median load time, global" — that answers nothing. The value is in the splits, so attach them to every beacon: geography and network type; device class and browser; page template (product page vs checkout, not raw URLs); protocol negotiated (your HTTP/3 share, measured for free); and — the one almost everyone misses — cache status of the HTML, exposed via a response header the script can read or a Server-Timing stamp. That last dimension lets field data reproduce the edge-vs-origin split from the TTFB guide at population scale: hit-path experience versus miss-path experience, per country, per template. Five well-chosen dimensions multiply the value of the data; fifty multiply only the storage bill.
From dashboards to decisions
Report percentiles, never averages — p75 as the headline, p90/p95 to see the tail where delivery problems live, and always with the sample count beside the number so nobody reads a 40-user segment as gospel. Then wire the data into decisions, because unlooked-at RUM is a subscription, not a capability: a weekly glance at p75 by country against last week; a regression review after every delivery change (TTL policy, compression, protocol, provider); and one standing question — "which segment got worse?" — owned by a named person. The endgame is that arguments about speed end with someone pulling up the segment instead of an opinion, and delivery changes ship with a before/after attached. That is the entire return on the deployment, and it costs one habit.