Real User Monitoring (RUM) Overview
Overview
Real User Monitoring (RUM) helps you understand how your application performs for real users in the real world. It gives the full insight of users' journey across devices, browsers, and locations that helps in identifying and resolving performance issues.
RUM is essential for engineering and product teams building any digital application from customer-facing platforms to internal portals, because it monitors the user experience with a view to actual speed, smoothness, and reliability of the application.
By leveraging RUM, you can:
- Track how each session, view, and action performs in real time.
- Visualize page load timings, interaction delays, content stability, and rendering issues.
- Observe the complete loading sequence of view components with a timeline of resource-level events.
- Slice data by browser, device, geo-location, and application versions.
- Map user behavior to performance bottlenecks and errors.
Whether you’re focused on optimizing web vitals or reducing friction in user flows, RUM helps with the user-centric observability layer that your frontend needs.
Holistic KPIs Tracked in RUM
| KPI | Description |
|---|---|
| Loading Time | This represents the total time it takes for a page to become fully interactive after the initial request. It's a comprehensive indicator of performance covering load scripts, assets, and DOM readiness. |
| Largest Contentful Paint (LCP) | Measures the time it takes for the largest visible content element (image, video, or text block) to load and render within the viewport. It reflects perceived load speed and plays a critical role in user experience, particularly on landing pages. |
| First Contentful Paint (FCP) | It captures the time when the browser first renders any content (text/image/SVG) from the DOM. It is the first visual feedback a user sees, indicating that something is happening. |
| Cumulative Layout Shift (CLS) | Measures the visual stability of a page and quantifies how often users experience unexpected layout shifts. |
| Interaction to Next Paint (INP) | INP measures responsiveness by evaluating the time taken from a user's interaction (e.g., click or key press) to the next visual update. |
| Apdex Rating | Apdex (Application Performance Index) scores user satisfaction based on response time. It divides users into Satisfied, Tolerating, and Frustrated categories and calculates a normalized score between 0 and 1. |
How RUM Helps
| Persona | Key Questions Answered by RUM |
|---|---|
| Frontend Developer | Which views are rendering slow? Are layout shifts affecting UX? Are errors concentrated in specific browsers or JS libraries? |
| DevOps / SRE | What is the performance trend by region or device? Are releases degrading page vitals or increasing interaction delays? |
| Product & CX Teams | Which user actions result in rage clicks or drop-offs? How is the experience across geographies? Are users frustrated by performance issues? |
Severity Mapping Based on RUM Thresholds
RUM metrics are mapped to severity levels to identify performance concerns. The severity levels for each KPIs are considered as following.
| KPI | Thresholds | Severity / Color |
|---|---|---|
| Loading Time | LT ≤ 2.5s | 🟢 Good |
| 2.5s < LT ≤ 4.0s | 🟠 Needs Improvement | |
| LT > 4.0s | 🔴 Poor | |
| Largest Contentful Paint (LCP) | LCP ≤ 2.5s | 🟢 Good |
| 2.5s < LCP ≤ 4.0s | 🟠 Needs Improvement | |
| LCP > 4.0s | 🔴 Poor | |
| First Contentful Paint (FCP) | FCP ≤ | 🟢 Good |
| 1.8s < FCP ≤ 3.0s | 🟠 Needs Improvement | |
| FCP > 3.0s | 🔴 Poor | |
| Cumulative Layout Shift (CLS) | CLS ≤ 0.1 | 🟢 Good |
| 0.1 < CLS ≤ 0.25 | 🟠 Needs Improvement | |
| CLS > 0.25 | 🔴 Poor | |
| Interaction to Next Paint (INP) | INP ≤ 200ms | 🟢 Good |
| 200ms < INP ≤ 500ms | 🟠 Needs Improvement | |
| INP > 500ms | 🔴 Poor | |
| Apdex Rating | 0.94 < AR ≤ 1.00 | 🟢 Excellent |
| 0.85 < AR ≤ 0.94 | 🟡 Good | |
| 0.70 < AR ≤ 0.85 | 🟠 Fair | |
| 0.50 < AR ≤ 0.70 | 🔴 Poor | |
| 0.00 < AR ≤ 0.50 | 🔴 Unacceptable |
Formula used for Apdex Rating is,
Apdex Rating= (Satisfied + 0.5 × Tolerating) / Total Sessions
Apdex Rating uses a threshold T = 2s where:
- Satisfied: Response time ≤ T
- Tolerating: T < Response time ≤ 4T
- Frustrated: Response time > 4T
Real-World Use Cases for RUM
| Use Case | Description |
|---|---|
| Optimize Page Loading Time | Identify slow views or resources dragging down page performance. |
| Monitor Core Web Vitals | Track LCP, FCP, CLS, and INP across different browsers, geo-locations, device type, and application versions. |
| Track Real-Time Errors | Surface front-end exceptions, failed resource loads, and JS issues. |
| Behavior-to-Performance Correlation | Combine session replay with performance metrics to pinpoint friction points. |
| Session Debugging | Investigate poor experiences using session replays, view trees, and event flows. |