Running & Maintaining a Site

Real User Monitoring

Definition

Real user monitoring collects timings and errors from genuine sessions rather than from a test agent. A small script in the page reads the browser's own performance entries and sends them back, so every measurement carries the device, connection, browser and location of a real person. The output is a distribution rather than a single number: the same page might load in 0.9 seconds at the median and 4.1 seconds at the 75th percentile, and the second figure is the one describing the people having a bad time. RUM covers whatever your audience actually uses — six-year-old phones on patchy mobile data as well as new laptops on fibre — which is exactly the range synthetic monitoring cannot reproduce. Its weakness is the mirror image of its strength: no visitors means no data, so it cannot tell you the site was unreachable overnight.

Why It Matters

Averages hide the problem. A page that feels quick on your own desk can be painfully slow for a third of its audience, and loading it yourself will never show you that. RUM is also the kind of measurement search engines use for field data, so its numbers are close to the ones behind a Core Web Vitals assessment. Watching the 75th percentile instead of the mean changes decisions: it is what tells you a 2 MB hero image is fine for most visitors and ruinous for the ones on mobile data, which is a different conclusion from the one an average offers.

How It Works

The browser exposes measurements through the Performance API, and a PerformanceObserver subscribes to the entry types you care about. Largest Contentful Paint reports when the biggest visible element finished rendering, layout-shift entries accumulate into a cumulative score, event-timing entries give interaction latency, and navigation timing supplies DNS, connection and time to first byte. Values are only final when the page is hidden, so the script listens for the visibilitychange event and posts its payload with navigator.sendBeacon, which is built to survive a page closing. Keep the payload small and free of identifiers — page path, timings, effective connection type, a coarse device category — both to keep the script light and to stay clear of consent requirements. On the receiving side, percentiles matter and averages do not, and you need enough sessions per page for the 75th percentile to mean anything at all.

Real-World Example

A shop publishes a 40-image lookbook at spring-lookbook.99helpers.site and it feels instant in the office. Field data tells a different story: a 1.2 second median, a 5.6 second 75th percentile, and nearly all of the slow end on mobile. The cause is full-resolution JPEGs scaled down in the markup rather than resized on disk. Swapping them for properly sized WebP versions with lazy loading pulls the 75th percentile to 1.9 seconds, while the average barely moves — which is precisely why the average was never going to reveal it.

Common Mistakes

  • Judging performance by the mean — it is dominated by fast sessions and stays flat while the slow tail quietly gets worse
  • Loading a heavy monitoring script to measure how slow a page is — the measurement should cost a few kilobytes, not a few hundred
  • Using RUM as an availability check — when the site is unreachable there are no sessions, so the dashboard goes quiet rather than red

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →