How to Set Up Real User Monitoring (RUM) for Your Website

Kunnskapsbase

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

Browse more articles in Performance & Monitoring.

Kunnskapsbase

Kategorier

Kategorier