Real User Monitoring
Real user monitoring, or RUM, collects performance measurements from people using your site or web application. It shows how real devices, networks, routes, and releases affect the experience, beyond what a controlled test can reproduce.
itObservability and performance | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Real User Monitoring
Real user monitoring, or RUM, is the mildly unnerving act of asking a web application what happened when actual people used it. Not a carefully selected laptop on a clean network, but the assorted devices, caches, routes, and third-party responses that production has assembled while nobody was looking.
Before RUM, a team could run a lab test and receive a neat answer for one chosen scenario. That answer remains useful. It gives you a trace and a waterfall for reproducing trouble. It cannot tell you whether the mobile checkout route felt slow for a real population after Tuesday's release. Field data supplies that missing, gloriously inconvenient part of the story.
The browser already keeps a performance timeline, a collection of timing entries about navigation, resources, and application work. A PerformanceObserver receives the selected entries. The important word is selected. A RUM record is not a ceremonial attempt to mail the browser to a database. It is a small record containing the metric, a route class, device category, release identifier, and only the context needed to compare like with like.
Start with a user outcome. Largest Contentful Paint describes loading, Interaction to Next Paint describes responsiveness, and Cumulative Layout Shift describes unexpected visual movement. Those names sound as though they might settle an argument. They do not. They say what a population experienced. Navigation timing, resource timing, long tasks, and a lab trace help test why.
The useful number is usually a percentile over a defined population. Keep the route, device group, time window, and sample size in view. A changed percentile can follow a release, but it can also follow changed traffic or changed collection. The dashboard is evidence, not a tiny electronic judge in a wig.
Begin with one route, one outcome, and one useful segment. The Intro explains the browser evidence and data path. Slides compress the comparisons into a map. Cheatsheet keeps the metrics and operating loop close at hand. Field Notes covers the operational traps that charts politely decline to mention. The exercise lets you build a narrow probe without collecting production data.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://web.dev/articles/user-centric-performance-metrics
Supports
- Field measurement captures real users loading and interacting with a site
- Lab and field measurements serve complementary purposes
- Device capability, network conditions, interaction, personalization, and ads can make user experiences vary
- Real user measurement is commonly called RUM
- https://web.dev/articles/vitals
Supports
- LCP measures loading, INP measures interactivity, and CLS measures visual stability
- Good thresholds are LCP 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less
- Core Web Vitals guidance evaluates the 75th percentile separately for mobile and desktop
- Chrome User Experience Report supplies anonymized real-user measurements and does not provide detailed per-pageview telemetry
- Sites should set up their own real-user monitoring for detailed telemetry
- https://www.w3.org/TR/performance-timeline/
Supports
- Performance Timeline stores and retrieves high-resolution performance metric data
- PerformanceObserver receives selected new and optionally buffered performance entries
- Observers should subscribe only to needed entry types to reduce event volume
- https://www.w3.org/TR/navigation-timing-2/
Supports
- PerformanceNavigationTiming stores and retrieves high-resolution timing data for a document navigation
- https://www.w3.org/TR/resource-timing/
Supports
- PerformanceResourceTiming provides client-side measurements for fetched resources and their phases
- Resource Timing includes cross-origin resource considerations
- https://www.w3.org/TR/longtasks/
Supports
- Long tasks can block queued input and affect responsiveness
- Long Tasks API surfaces tasks that take 50 milliseconds or more
- https://web.dev/articles/crux-and-rum-differences
Supports
- RUM uses site-included code to collect and analyze field data
- RUM can collect custom metrics and apply site-specific segmentation
- Small or unrepresentative samples can skew reported metrics
- https://engineering.linkedin.com/performance/how-linkedin-used-pops-and-rum-make-dynamic-content-download-25-faster
Supports
- LinkedIn used browser-side RUM measurements to inform network and point-of-presence decisions
- Synthetic-agent distribution can differ from a real user population
- https://engineering.atspotify.com/2022/9/from-development-to-real-users-how-to-create-a-web-performance-story
Supports
- Spotify used field data to evaluate how changes affected real users
- Lab measurements and field data have complementary roles in a performance workflow
- https://www.w3.org/standards/history/navigation-timing.html
Supports
- Navigation Timing entered working draft in 2010 and became a Recommendation in 2012
- https://www.w3.org/standards/history/performance-timeline.html
Supports
- Performance Timeline became a Recommendation in 2013
- https://www.w3.org/standards/history/resource-timing.html
Supports
- Resource Timing became a Recommendation in 2014
- https://www.w3.org/standards/history/user-timing.html
Supports
- User Timing Level 2 became a Recommendation in 2016
- https://www.w3.org/standards/history/longtasks.html
Supports
- Long Tasks became a Recommendation in 2018
- https://developer.chrome.com/blog/new-in-chrome-83
Supports
- Chrome introduced Core Web Vitals in 2020 around loading, interactivity, and visual stability
- https://web.dev/articles/inp
Supports
- INP was introduced in 2022 and measures responsiveness across page interactions
- Field RUM can provide context about slow interactions
- https://web.dev/blog/inp-cwv-launch
Supports
- INP became a stable Core Web Vital in March 2024 and replaced FID
- https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/
Supports
- Datadog Browser RUM analyzes real-user performance and user journeys
- https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/instrumentation-browser-monitoring/
Supports
- New Relic Browser instruments page loads, SPA activity, AJAX calls, and JavaScript errors
- https://docs.dynatrace.com/docs/semantic-dictionary/model/rum
Supports
- Dynatrace RUM models user events and sessions for application frontends
- https://www.elastic.co/docs/solutions/observability/apm/real-user-monitoring-rum
Supports
- Elastic provides a RUM JavaScript agent for client-side experience monitoring
- https://grafana.com/oss/faro/
Supports
- Grafana Faro is an open-source web SDK for frontend observability
