Real user monitoring (RUM) measures what actual users experience. A JavaScript agent, typically 5 to 20KB, runs in each page, reads the browser's own performance APIs, and sends timing data, errors and Core Web Vitals to a collection endpoint, preferably with navigator.sendBeacon(). Synthetic monitoring runs scripted tests from defined locations; RUM records real sessions on real networks, devices and browsers. Digital experience monitoring (DEM) is the broader discipline: it adds session replay and links each user session to the backend traces that served it.
Everything your backend infrastructure monitoring tells you may be true, and your users may still be having a terrible experience. This is the central paradox of modern web application operations, and it is why Real User Monitoring exists.
Your servers can be healthy, your APIs responding in under 100ms, and your error rates at baseline — while your users in a specific geography, on a specific mobile carrier, using a specific browser version, are experiencing 8-second load times and broken layouts. Infrastructure monitoring will never show you this. Only monitoring the actual user experience will.
Real User Monitoring (RUM) and the broader discipline of Digital Experience Monitoring (DEM) represent the shift from infrastructure-out observability to user-in observability. They measure what actually reaches users — accounting for network latency, CDN behavior, browser rendering, third-party scripts, and device variability — rather than what your servers produced.
This guide covers the technical architecture of RUM, the emerging standard of Core Web Vitals, how to connect user experience data to backend performance signals, and how to build a monitoring strategy that genuinely reflects the experience of your users.
What is the difference between RUM and synthetic monitoring?
Synthetic monitoring runs scripted, automated tests against your application from defined locations at regular intervals. It is proactive — it tells you whether your application is available and how it performs under controlled, predictable conditions, even when no real users are present.
Real User Monitoring collects performance data from actual users' browsers and devices as they interact with your application in real-world conditions. It is reactive — it tells you what your users are actually experiencing, with all the variability of real network conditions, device diversity, and behavioral patterns.
| Dimension | Real User Monitoring (RUM) | Synthetic Monitoring |
|---|---|---|
| Data source | Actual user sessions | Scripted automated probes |
| Coverage | All users, all paths | Defined scripts, defined locations |
| When available | Only when users are active | 24/7, including off-hours |
| Variability captured | Full real-world variability | Controlled, consistent conditions |
| New issue detection | Reactive (when users hit it) | Proactive (before users hit it) |
| Best for | Understanding actual user impact | SLA verification, proactive alerting |
| Blind spots | Off-hours issues; new flows users haven't visited | Variability; unexpected user behaviors |
The correct architecture uses both: synthetic monitoring for baseline availability and SLA verification, RUM for understanding actual user experience and diagnosing real-world performance issues. Synthetic monitoring vs. real user monitoring covers when to use each.
How does real user monitoring work?
RUM is implemented by injecting a JavaScript agent (a small snippet of code, typically 5–20KB) into each page of the monitored application. This agent runs in the user's browser and collects performance and behavioral data, which it transmits to a collection endpoint.
Data Collection Mechanisms
The RUM agent leverages browser-native APIs to collect performance data with minimal overhead:
Navigation Timing API: Provides a detailed breakdown of the page load process — DNS lookup, TCP connection, TLS handshake, server response time (TTFB), resource download, DOM parsing, and rendering. This data is available for every page load, for every user, without any instrumentation beyond the RUM agent itself.
Resource Timing API: Records timing data for every resource loaded by the page — JavaScript files, CSS, images, API calls, fonts. Enables identification of slow-loading third-party resources that impact page performance.
User Timing API: Application developers can add custom marks and measures to the performance timeline — for example, marking the moment a key UI component becomes interactive. This bridges RUM and application-level performance measurement.
Long Tasks API: Reports JavaScript tasks that block the browser's main thread for more than 50ms. Long tasks are a primary cause of poor interactivity and janky scrolling.
Largest Contentful Paint (LCP) Observer, Cumulative Layout Shift (CLS) Observer: Web Vitals APIs that measure user-perceived rendering metrics.
Data Transmission
Collected performance data is batched and sent to the RUM collection endpoint using:
navigator.sendBeacon(): The preferred mechanism — sends data asynchronously after the page interaction, without blocking page unload or impacting page performanceXMLHttpRequest/fetch: Used for older browsers without Beacon API supportreportingObserver: For newer browser reporting APIs
Sampling RUM for High-Traffic Applications: On very high-traffic sites, collecting 100% of user sessions generates enormous data volumes and storage costs. Most RUM platforms support configurable session sampling. A 10% sample on a 10M-session/day application still provides statistically robust performance data across all user segments. However, always retain 100% of sessions with errors or extreme latency — these are the diagnostic goldmine.
Which Core Web Vitals does RUM measure?
Google's Core Web Vitals (CWV) are metrics for web application user experience, used both for technical monitoring and for search engine optimization. Understanding these metrics is essential for any technology leader responsible for web application performance.
The Three Core Web Vitals
Largest Contentful Paint (LCP): Measures loading performance. Specifically, the time from page navigation start until the largest visible content element (image, video poster, block-level text) finishes rendering. LCP represents when the user perceives the page as "loaded."
- ✅ Good: ≤ 2.5 seconds
- ⚠️ Needs improvement: 2.5–4.0 seconds
- ❌ Poor: > 4.0 seconds
Interaction to Next Paint (INP): Measures responsiveness — the latency of all user interactions (clicks, taps, keyboard input) throughout the page session. INP replaced the deprecated First Input Delay (FID) metric in March 2024. INP is more comprehensive because it measures all interactions, not just the first.
- ✅ Good: ≤ 200 milliseconds
- ⚠️ Needs improvement: 200–500 milliseconds
- ❌ Poor: > 500 milliseconds
Cumulative Layout Shift (CLS): Measures visual stability — how much the page layout shifts unexpectedly during loading. Sudden layout shifts (caused by images without dimensions, dynamically injected content, web fonts causing text reflow) create a jarring user experience.
- ✅ Good: ≤ 0.1
- ⚠️ Needs improvement: 0.1–0.25
- ❌ Poor: > 0.25
Google says good Core Web Vitals, along with other page experience aspects, align "with what our core ranking systems seek to reward" (Google Search Central). For enterprises managing high-traffic websites, CWV scores have direct SEO and organic traffic implications — making performance monitoring a cross-functional concern spanning engineering, product, and marketing.
Measuring Core Web Vitals in Practice
CWV data is available from two sources:
Lab data (synthetic): Measured in controlled environments using tools like Google Lighthouse (built into Chrome DevTools), WebPageTest, or synthetic monitoring platforms. Consistent, reproducible, available for any URL at any time. Does not reflect real user variability.
Field data (RUM): Measured from actual users via the web-vitals JavaScript library or RUM platforms. Reflects real-world conditions — device speed, network quality, geographic distribution. This is the data Google uses for ranking signals.
The correct approach for enterprise applications: use lab data for development feedback loops and regression detection in CI/CD pipelines; use field data (RUM) for understanding actual user experience and setting performance improvement priorities.
Session Replay: The Qualitative Layer
Beyond quantitative performance metrics, modern RUM platforms include session replay — the ability to record and replay actual user sessions as a video-like reconstruction of their experience. Session replay captures:
- Every mouse movement, click, and scroll
- Form interactions (with automatic PII redaction for sensitive fields)
- JavaScript errors and their stack traces
- Network requests made during the session
- The page's visual state at every moment
Session replay transforms RUM from a metrics system into a qualitative investigation tool. When a user reports that "the checkout button doesn't work," session replay shows the engineer exactly what the user saw, what they clicked, and what error occurred — without requiring reproduction steps.
PII and Privacy Considerations for Session Replay
Session replay raises legitimate privacy concerns. Best practices:
- Automatic input masking: All form inputs (particularly password fields, credit card numbers, and personally identifiable information) should be masked by default in session replay recordings
- Element exclusion: Sensitive UI elements (patient health information, financial account details) can be explicitly excluded from recording
- IP anonymization: User IP addresses should be anonymized or hashed before storage
- Consent and disclosure: Session replay must be disclosed in privacy policies; some jurisdictions (GDPR, CCPA) may require explicit consent
Session Replay and GDPR: In EU-regulated environments, session replay that captures user behavior may constitute processing of personal data under GDPR. Consult your data protection officer before deploying session replay on applications serving EU users. Ensure your vendor's data processing agreements cover session replay data and that data residency requirements are met.
How should you segment RUM data?
Aggregate RUM metrics (average LCP across all users: 2.1 seconds) are directionally useful but operationally limited. The real diagnostic power of RUM emerges from segmentation — filtering performance data by dimensions that reveal the specific populations experiencing degraded performance.
High-Value Segmentation Dimensions
Geography: Network latency, CDN coverage, and ISP quality vary dramatically by region. A page loading in 1.2 seconds in New York may load in 5.8 seconds in Lagos. Geographic RUM segmentation identifies coverage gaps in CDN configuration, missing Points of Presence, and region-specific performance regressions.
Device and browser: Mobile devices with constrained CPU and memory, older Android browsers, and specific browser versions may experience performance issues invisible in desktop testing. RUM segmentation by device class and browser version surfaces these populations.
Network type: 4G vs. WiFi vs. 3G vs. 2G network connections produce dramatically different loading performance. High-value user segments in markets with predominantly mobile data connectivity (Southeast Asia, Africa) require specific performance optimization strategies.
User segment / cohort: Segmenting performance by logged-in user attributes (subscription tier, account age, user role) reveals whether performance degradation disproportionately affects specific customer segments. Premium users experiencing worse performance than free users is a business problem as much as a technical one.
Page type / route: Home page performance optimizations often do not translate to product detail pages, checkout flows, or account management pages. Route-level RUM segmentation enables targeted optimization.
Deployment cohort: After deploying a new version, comparing RUM performance between users served the new version vs. users on the previous version (via canary deployment or feature flag) provides real-world regression detection before full rollout.
How do you connect RUM to backend traces?
The most operationally valuable capability in modern DEM platforms is the connection between frontend user experience metrics and backend distributed traces. This correlation closes the full-stack visibility gap.
The architecture:
- The RUM agent generates a session ID and injects it into all XHR/fetch requests made by the browser as a custom HTTP header
- Backend services extract this session ID and include it as a span attribute in their distributed traces
- The observability platform links the RUM session to the backend trace, enabling navigation from a slow user session to the backend trace that served it
With this integration in place, the investigation workflow becomes:
- RUM dashboard shows increased LCP in the checkout flow over the past 2 hours
- Filter to affected sessions: users on Chrome Mobile in Southeast Asia
- Select a representative slow session — navigate from session replay to backend trace
- Backend trace reveals the payment service is calling a slow external fraud API
- Root cause identified: increased fraud scoring latency from a third-party vendor affecting mobile users in specific geographies
This end-to-end investigation, fully connected from the user's browser experience to a specific backend span, would previously have required hours of manual correlation across multiple tools. With integrated RUM + tracing, it is minutes.
Vendor Ecosystem Overview
Full-Stack DEM Platforms
- Dynatrace Real User Monitoring — Full-stack DEM with automatic injection, session replay, and tight integration with backend distributed tracing via OneAgent.
- Datadog RUM — Part of the Datadog platform. Session replay, Core Web Vitals tracking, and trace correlation.
- New Relic Browser — RUM with JavaScript error tracking, integrated with New Relic APM.
- Elastic RUM (User Experience) — Open-source RUM agent with commercial backend.
Datadog vs. Dynatrace and Datadog vs. New Relic compare three of these platforms side by side.
Specialist RUM and Web Performance
- SpeedCurve — Web performance monitoring with Core Web Vitals tracking and competitive benchmarking.
- Calibre — Developer-focused performance monitoring with CI/CD integration for performance regression prevention.
- mPulse (Akamai) — RUM integrated with Akamai's CDN.
Open-Source
- web-vitals (Google) — JavaScript library for collecting Core Web Vitals in-browser. Typically used with a custom backend or analytics pipeline.
- Boomerang (SOASTA/Akamai open-source) — Open-source RUM beacon library.
- OpenTelemetry Browser SDK — Browser-side OpenTelemetry instrumentation for vendor-neutral browser telemetry.
Buyer Evaluation Checklist
RUM / Digital Experience Monitoring Platform Evaluation
Core RUM Capabilities
- Browser performance API coverage (Navigation Timing, Resource Timing, Long Tasks)
- Core Web Vitals measurement (LCP, INP, CLS) with percentile breakdowns
- JavaScript error capture with stack traces and source map support
- AJAX/fetch request monitoring with status and timing
- Single-page application (SPA) route change tracking
Session Replay
- Session replay with automatic PII/sensitive data masking
- Configurable element exclusions for sensitive UI components
- JavaScript error context in session replay timeline
- Session filtering and search by user attributes, error type, or performance tier
Segmentation and Analysis
- Geographic performance breakdown
- Device and browser segmentation
- Network type segmentation
- Custom user attribute segmentation (requires SDK integration)
- Deployment/version performance comparison
Backend Correlation
- Trace correlation (RUM session → backend distributed trace)
- Infrastructure correlation (RUM latency → CDN / server metrics)
- End-to-end waterfall view (browser → network → server)
Alerting
- Core Web Vitals threshold alerting
- Error rate anomaly detection
- Geographic performance degradation alerts
- Deployment regression alerts (automatic comparison on deploy)
Privacy and Compliance
- GDPR-compliant data collection and processing
- Data residency options (EU, US, APAC)
- IP anonymization
- Cookie-free measurement option (for consent-required environments)
Key Takeaways
Real User Monitoring closes the most important visibility gap in application observability: the gap between what your infrastructure produces and what your users actually experience. No server-side monitoring system, regardless of its sophistication, can substitute for measuring the actual browser, network, and device conditions that shape user experience.
The Core Web Vitals framework provides an excellent measurement foundation — three metrics with clear thresholds and direct SEO implications. Session replay adds the qualitative dimension that pure metrics cannot provide. And backend trace correlation connects user experience signals to the infrastructure events that cause them.
Organizations that invest in full-stack DEM — browser through backend — gain the ability to understand and improve their digital products from their users' perspective, not just their infrastructure's perspective. In an era where user experience directly drives revenue, retention, and brand perception, that visibility is a strategic necessity.
Independent. No sponsorships. Unsubscribe anytime.