Real User Monitoring (RUM): Definition and Examples

What is Real User Monitoring (RUM)?

Real User Monitoring (RUM) measures how your site performs for the people actually using it. A small script in the page records load timings, interaction delays, layout shifts and errors in each visitor's browser and sends them to a backend. The result is field data from real devices, networks and countries, not a scripted test.

How RUM works

The script uses standard browser APIs such as PerformanceObserver, collects metrics as the page loads and is used, and ships them out in batches. The reliable moment to send is when the page becomes hidden, because the older unload events often never fire on mobile. navigator.sendBeacon() exists for this: it queues a small POST that does not delay the page leaving (MDN reference).

new PerformanceObserver((list) => {  for (const entry of list.getEntries()) {    send({ metric: 'lcp', value: entry.startTime });  }}).observe({ type: 'largest-contentful-paint', buffered: true });document.addEventListener('visibilitychange', () => {  if (document.visibilityState === 'hidden') {    navigator.sendBeacon('/rum', JSON.stringify(queue));  }});

On the backend, each beacon is tagged with context such as browser, device, country and page, then aggregated into percentiles you can slice.

What RUM measures

• Loading: time to first byte, First Contentful Paint and Largest Contentful Paint.
• Responsiveness: Interaction to Next Paint and long tasks.
• Visual stability: Cumulative Layout Shift.
• Errors: JavaScript exceptions, failed requests and unhandled promise rejections.
• Context: browser, operating system, device class, connection type, country and release version.
• Business events: signup completed, checkout started, to tie speed to outcomes.

The three that matter most for search and user experience are the Core Web Vitals. Google's guidance (web.dev) is LCP within 2.5 seconds, INP at 200 milliseconds or less and CLS at 0.1 or less, judged at the 75th percentile of page loads, segmented by mobile and desktop.

RUM vs synthetic monitoring

Use both. Synthetic checks tell you something broke at 3 a.m. and give comparable numbers run over run. RUM tells you who is affected and whether a fix helped. The post synthetic monitoring vs real user monitoring goes deeper on choosing between them.

Example: a slow checkout on mobile

Synthetic tests on a desktop-class machine show the checkout page loading fine. RUM, segmented by device, shows the 75th percentile LCP on mid-range Android phones well above the 2.5 second target, concentrated on one country. The cause turns out to be an oversized hero image. After the fix ships, the same RUM view confirms the percentile moved, which a lab test alone could not prove.

Common RUM mistakes

• Reading averages. Averages hide the slow tail. Track p75 and p95.
• Not segmenting. Mobile and desktop, fast and slow connections behave very differently, and a blended number hides both.
• Collecting personal data. Keep URLs free of tokens and emails, avoid unnecessary identifiers and follow your privacy obligations. Check your consent requirements with your own legal advice.
• Alerting on every blip. Alert on sustained regressions of a percentile, not single sessions.
• Forgetting single-page apps. Route changes do not reload the page, so they need explicit page-view markers.
• Expecting RUM to detect outages. No visitors means no signal. Pair it with scheduled checks.

RUM, CrUX and LoadFocus

The Chrome UX Report (CrUX) is public RUM data from opted-in Chrome users, aggregated per origin. It is good for seeing how Google views your site and for comparing origins. Your own RUM covers every browser and carries your own dimensions, which makes it better for debugging. LoadFocus does not run a RUM script. Page speed monitoring gives you the other half: Lighthouse audits from 25 cloud regions on a schedule, plus CrUX field data with a Core Web Vitals pass or fail badge. For uptime and response checks on your backend, see API monitoring. RUM is the browser side of application performance monitoring.

FAQ: Real User Monitoring

Is RUM the same as APM?

No. APM watches the backend: servers, services and database calls. RUM watches the frontend in the visitor's browser. Combined they give a full picture of a request from click to response.

Does RUM slow down my site?

A little, if done badly. Load the script asynchronously, keep it small and send data with sendBeacon so it never blocks the page. Measure the script's own cost before you roll it out.

What is the difference between RUM and CrUX?

CrUX is a public dataset of Chrome users' experiences, aggregated per origin and page group. RUM is your own collection: every browser, your own sessions and custom dimensions such as release or experiment variant.

Can I do RUM without a vendor?

Yes. Google's open-source web-vitals library reports the Core Web Vitals in the browser, and you send them to your own endpoint with sendBeacon. You then have to store, aggregate and chart them yourself.

Is RUM allowed under GDPR?

It depends on what you collect and how. Performance timings are far less sensitive than session recordings or user identifiers. Anonymise what you can, keep identifiers out of URLs, document it in your privacy policy and ask your legal advisor whether you need consent.