User-Perceived Performance Monitoring (RUM)
For modern web applications (especially SPAs), what happens on the client is the core of the user experience. No matter how fast the server responds, if browser rendering or AJAX calls are slow, customers still perceive the service as "slow." This guide covers how to continuously monitor Real User Monitoring (RUM) performance using WhaTap Browser Monitoring.
Synthetic Monitoring vs. RUM — the Difference
Synthetic Monitoring runs predefined scenarios on a regular schedule to measure performance, availability, and functionality in a simulated environment. It's useful for checking 24/7 availability even during traffic-free hours overnight, establishing a regression-testing baseline before a new deployment, or verifying response times from external locations in different regions. Lighthouse, PageSpeed Insights, and URL monitoring are representative tools.
RUM (Real User Monitoring) uses performance data collected directly from real users' browsers. Because it reflects the actual perceived speed across a variety of devices, networks, and regions, it surfaces "real-world problems" that synthetic monitoring can't catch.
The key difference is a baseline under ideal conditions (Synthetic) vs. the actual user experience (RUM). The two approaches are complementary, and neither is sufficient on its own. Ultimately, service-quality SLAs must be managed with RUM data.
| Tool | Measurement method | Strengths | Limitations |
|---|---|---|---|
| Browser DevTools | Local, by developers | Debugging and fine-tuning | Not suited for continuous monitoring |
| Google Lighthouse | Synthetic | Comprehensive performance, accessibility, and SEO | Doesn't reflect real user data |
| PageSpeed Insights | Synthetic + CrUX | Core Web Vitals benchmarks | Limited to specific conditions and deep tracing |
| Web Vitals Extension | Browser extension | Quick Core Web Vitals check | Lacks tracing for complex performance issues |
| WhaTap RUM | Real users | Actual perceived performance, continuous tracking, down to the error's code location | — |
RUM in WhaTap Browser Monitoring
① Real-Time Page Load / AJAX Statistics
You can check the load time of pages users actually opened and the response time of AJAX calls on a real-time dashboard.
- Page load distribution: see the ratio of fast vs. slow users at a glance
- AJAX call performance: failure rate and response time by API
- Drag to select only the slow segments → drill into the details
② Error Tracking — Down to the Code Line
Collects JavaScript errors that occur in real users' browsers so you can quickly find the file and code line where the error occurred. Identify the cause quickly, without reproducing the issue or remote debugging.
Combining this with AI error stack analysis cuts the interpretation time even further.
③ Analyzing the User's Access Environment
Check the performance distribution by browser, OS, device, and region to catch issues that appear only in specific environments early.
Usage Scenarios
Checking the User-Perceived Change After a New Feature Release
- Compare the page load time distribution right before and after the deployment
- Check whether new slow endpoints appear among AJAX calls
- Check whether new JS errors appear in error tracking
- Cross-check against results from synthetic monitoring tools → Release verification scenario
Managing SLAs and Core Web Vitals
- Include RUM-based p75 response time and Core Web Vitals like LCP/FID/CLS in the monthly performance report → Performance reporting scenario
- Track the SLA non-compliance rate
An Early Signal for Incident Alerts
Server metrics can look normal while users still experience degraded performance (CDN, DNS, network path, etc.). RUM acts as a detection net that catches problems outside the server → also consider adding RUM-based rules when you attach your first alert.
Relationship to the Existing Browser Monitoring Guide
- Using the browser monitoring — how to analyze the 4 areas: page load, AJAX, access environment, and errors
- This guide (the RUM perspective) — managing real user data as "SLA and user experience metrics"
Reading both together gives you both a functional understanding and an operational perspective.
Next Steps
- Browser installation and setup — Browser Monitoring
- AI error analysis → Using AI browser error stack analysis (see tracking-error.mdx)
- Combine with synthetic monitoring → URL monitoring: URL
- Connect client-side anomalies with the server side → Incident response scenario