Real User Monitoring
Collecting performance from the people actually using your site, and reading the distribution they produce.
RUM is where the abstract metrics become a living dashboard. You drop a tiny script in your page, and every real visit quietly reports back — building a picture of how your site actually performs for everyone, not just for you on your fast laptop. Here's how it works, and how to read it without getting fooled by averages.
How RUM collects data
A RUM tool is usually a small third-party snippet that loads early, listens for the Web Vitals as they finalize, and sends them in a beacon — typically when the page is hidden or unloaded, so it never delays anything. The service aggregates millions of these into the distributions you analyze:
Wiring it up
Setup is genuinely a copy-paste. Tools like New Relic (the one from the episode), SpeedCurve, or Sentry hand you a snippet keyed to your account; you drop it high in <head> so it initializes before the page loads:
<head>
<!-- RUM agent: must run early to capture the full load -->
<script src="https://js-agent.newrelic.com/…"></script>
<script>
window.NREUM || (NREUM = {});
NREUM.init = { /* trustKey, accountID, agentID, licenseKey */ };
</script>
<!-- the rest of your head -->
</head>The dashboard
A good RUM dashboard leads with a Core Web Vitals breakdown: the p75 for each metric, the share of users in good/needs-work/poor, and a load-time breakdown (TTFB → network → DOM processing → render) so you can see which stage is slow. Play with the mock dashboard below:
The power move: segment everything
The single most valuable thing RUM gives you is the ability to break the data down — by country, device, browser, connection, even by individual URL. An “okay” global average almost always hides a segment that's suffering. Filtering to that segment turns “the site feels slow for some people” into “mobile users in India are blocked on a 1.6 s network stage on the /checkout page.”
Many RUM tools also offer session traces — a per-visit timeline of backend time, DOM processing, and events, with errors pinned to the file and line — so you can zoom from “a segment is slow” all the way down to one user's bad session.
- →RUM is a lightweight snippet that beacons each real visit's metrics to a dashboard.
- →Read it via p75, the good/needs/poor split, and a stage breakdown (TTFB → network → DOM → render).
- →Its superpower is segmentation — by geo, device, browser, connection, URL.
- →Keep it light; over-instrumenting makes the monitor the bottleneck.
- →Field (RUM) finds who's slow; hand that segment to the lab to debug.