RUM Real User Monitoring

Collect field CWV and custom timings from real sessions: sampling, beacons, privacy, and dashboards.

intermediate3 min readUpdated Aug 4, 2026

performance
rum
web-vitals
field
analytics

Real User Monitoring (RUM) measures performance on actual devices and networks. CrUX is a public Chrome subset; your RUM covers logged-in flows, custom browsers, and business-specific timings.

Docs: web-vitals library, web.dev vitals, PerformanceObserver.

Minimum viable RUM

import { onLCP, onINP, onCLS, onTTFB } from 'web-vitals';

function send(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    route: location.pathname,
    navigationType: metric.navigationType,
  });
  navigator.sendBeacon('/rum', body);
}

onLCP(send);
onINP(send);
onCLS(send);
onTTFB(send);

Use attribution builds when debugging which element or event caused the metric.

What else to capture

Signal	Why
Route / template	Segment failures
Device class / UA-CH	Mobile vs desktop
Country / network (coarse)	CDN issues
User Timing marks	Business steps (add_to_cart)
Errors	Correlate with slow sessions
Sample rate	Cost control

Sampling and cost

100% of page views × rich resource timelines can be expensive. Sample (e.g. 10%) for heavy payloads; keep 100% for CWV if volume allows. Cap resource entries and scrub tokens from URLs — Resource Timing.

Privacy

No passwords, emails, or full card numbers in custom marks
Respect DNT / consent modes where legally required
Aggregate before long retention
IP truncation at the edge

Beacons and lifecycle

Flush on visibilitychange hidden — visibilitychange. Prefer sendBeacon / fetch keepalive.

Dashboard questions

Which templates fail p75 LCP/INP/CLS?
Regression after deploy X?
Third-party spike correlation?
Auth vs anon difference?

Lab tools don’t answer these alone — lab vs field.

Interview out-loud

“RUM collects field CWV with web-vitals plus route dimensions via beacons. I sample carefully, scrub PII, flush on page hide, and use dashboards to find failing templates before diving into lab profiles.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.