Knowledgebase

Real User Monitoring captures actual performance data from real visitors' browsers — complementing synthetic monitoring with genuine, varied real-world performance insight across different devices, networks, and locations.

RUM vs Synthetic Monitoring

Synthetic monitoring (see How to Set Up Uptime Monitoring for Your Website) tests from controlled, consistent locations/conditions; RUM captures performance data from your actual visitors' genuinely diverse real-world conditions — both are valuable, revealing different aspects of the performance picture.

What RUM Reveals That Synthetic Testing Doesn't

• Actual performance experienced by users on slow mobile connections or older devices
• Genuine geographic performance variation across your actual user base
• Real-world Core Web Vitals as actually experienced (not just lab-simulated)

Using the Browser's Native Performance API

<script>
window.addEventListener('load', () => {
  const perfData = performance.getEntriesByType('navigation')[0];
  const metrics = {
    ttfb: perfData.responseStart - perfData.requestStart,
    domLoad: perfData.domContentLoadedEventEnd - perfData.startTime,
    fullLoad: perfData.loadEventEnd - perfData.startTime,
  };
  navigator.sendBeacon('/rum-collect', JSON.stringify(metrics));
});
</script>

A basic self-built RUM approach using the browser's built-in Navigation Timing API, sending collected metrics to your own backend endpoint for aggregation.

Capturing Core Web Vitals Specifically

import {onLCP, onFID, onCLS} from 'web-vitals';

onLCP(sendToAnalytics);
onFID(sendToAnalytics);
onCLS(sendToAnalytics);

The web-vitals JavaScript library provides a reliable, standardized way to capture Core Web Vitals metrics (Largest Contentful Paint, First Input Delay, Cumulative Layout Shift) directly from real user sessions.

Building a Backend Endpoint to Collect RUM Data

Set up a lightweight API endpoint (see How to Build and Secure a REST API on a VPS) specifically for receiving RUM beacon data, storing it for later aggregation and analysis — consider a time-series-friendly database (see How to Set Up ClickHouse for Analytics Workloads) given the high volume of individual data points.

Aggregating and Visualizing RUM Data

Build dashboards (see How to Build a Monitoring Dashboard for Your Whole Team) showing distributions (not just averages, since individual user experience varies widely) — percentile-based views (median, 75th, 95th percentile) are more informative than a single average figure.

Segmenting RUM Data

Break down performance by device type, geographic region, and connection type — a single aggregate number can mask significant variation; segmentation reveals whether specific user segments experience meaningfully worse performance needing targeted attention.

Privacy Considerations

Be mindful of what data you're collecting from real users — avoid capturing personally identifiable information unnecessarily, and consider whether your data collection requires disclosure in your privacy policy depending on your jurisdiction and specific data handling.

Using a Third-Party RUM Service (Alternative to Self-Hosting)

Several commercial and open-source RUM platforms exist if building your own collection/aggregation pipeline is more effort than warranted for your needs — weigh the trade-off similarly to other self-hosted vs managed service decisions covered elsewhere in this Knowledge Base.

Common Errors

RUM data shows dramatically worse performance than your synthetic tests — expected and valuable finding, not necessarily an error; it reveals your synthetic testing location/conditions aren't representative of your actual user base's real experience.

Continue Reading

• How to Perform a Complete Website Speed Audit
• How to Build a Monitoring Dashboard for Your Whole Team
• How to Reduce Time to First Byte (TTFB)

Browse more articles in Performance & Monitoring.