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
Intro
Real User Monitoring
Real user monitoring, usually called RUM, records performance data while people use a web application. It answers a production question: what did people actually experience on this route, device, network, and release?
A lab test runs one chosen scenario. That makes it useful for diagnosis and repeatable checks. It cannot represent every device capability, connection, cache state, personalized response, or third-party response in production. RUM complements the lab by measuring the page as users load and interact with it.
What RUM measures
Browsers expose a performance timeline. It contains entries for navigation, fetched resources, user timing, and other supported metrics. A PerformanceObserver receives entries as they arrive and can also receive buffered entries for some metric types. RUM code selects the entries that matter, adds limited application context, and sends records to a collection service.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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