Real User Monitoring (RUM)

Also Known As

TL;DR

Explanation

RUM measures what users actually experience: page load times on 3G in Australia, JavaScript errors on older devices, Core Web Vitals distributions. It uses browser APIs (Navigation Timing, PerformanceObserver) to collect data and sends it to an analytics backend. Tools: Datadog RUM, Sentry (errors), web-vitals.js (custom RUM). Synthetic monitoring (Lighthouse, WebPageTest) tests ideal conditions; RUM reveals the p75/p95 tail that real users experience.

Common Misconception

Why It Matters

Common Mistakes

• Optimising only for Lighthouse scores without measuring real user data via CrUX or RUM.
• Not segmenting RUM data by device type, connection speed, or geography — global averages hide local problems.
• Not setting performance budgets based on RUM p75 — 50th percentile metrics look fine while the p90 is unacceptable.
• RUM script itself blocking page load — load the RUM beacon asynchronously and after user interaction data is collected.

Code Examples

// Synthetic only — misses real user conditions:
npx lighthouse https://example.com
// Score: 92 — team celebrates
// CrUX data: LCP p75 = 4.2s (Poor) on mobile
// Reason: Lighthouse uses cable throttling; real users on 4G are slower

// RUM with web-vitals.js:
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({ name, value, rating, id }) {
    navigator.sendBeacon('/analytics', JSON.stringify({
        metric: name, value, rating,
        url: location.href, connection: navigator.connection?.effectiveType
    }));
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

References

• ↗ https://web.dev/articles/vitals-measurement-getting-started
• ↗ https://github.com/GoogleChrome/web-vitals

Tags

Related Terms