Monitoring

Catchpoint Real User Monitoring: Measuring End-User Experience

HelpMeTest

HelpMeTest

— 7 min read
Catchpoint Real User Monitoring: Measuring End-User Experience

Synthetic monitoring tells you how your application performs under controlled conditions. Real User Monitoring (RUM) tells you how it performs for actual users — on their devices, on their networks, in their browsers. Catchpoint's RUM solution captures performance data from every real page view and surfaces the patterns that synthetic tests can't replicate.

This guide covers Catchpoint RUM implementation, key metrics, segmentation strategies, and how to use RUM data to make meaningful performance improvements.

What Is Real User Monitoring?

RUM works by injecting a small JavaScript snippet into your web pages. When a real user loads your page, the snippet:

  1. Captures browser performance timing data (Navigation Timing API, Resource Timing API)
  2. Measures Core Web Vitals (LCP, FID, CLS)
  3. Records user interaction timing
  4. Transmits the data beacon to Catchpoint's collection infrastructure

Unlike synthetic tests that run from known nodes on clean network conditions, RUM data reflects the full diversity of your actual user base:

  • Users on slow 3G connections in rural areas
  • Users on outdated browsers that parse JavaScript slowly
  • Users in countries with high latency to your servers
  • Power users on fiber connections seeing fast response

This diversity is precisely what makes RUM valuable — and why it complements rather than replaces synthetic monitoring.

Setting Up Catchpoint RUM

Step 1: Create a RUM Test in Catchpoint

Navigate to Test Library > Add Test > Real User Monitoring. Configure:

Name: Production RUM Monitor
Domain: yoursite.com (include subdomains if needed)
Data Retention: 30 days (or per your contract)
Sampling Rate: 100% (reduce for high-traffic sites)

Catchpoint generates a unique snippet ID tied to your RUM configuration.

Step 2: Add the JavaScript Snippet

Catchpoint provides a lightweight async script tag. Add it to the <head> of every page you want to monitor:

<head>
  <!-- Catchpoint RUM snippet -->
  <script>
    (function(c,a,t,ch,p,o,i,n,t2) {
      c[ch]=c[ch]||{};c[ch].api=p;
      var s=a.createElement(t);
      s.async=1;s.src=o;
      var f=a.getElementsByTagName(t)[0];
      f.parentNode.insertBefore(s,f);
    })(window,document,'script','_crum','https://rum.catchpoint.com/v1/','YOUR_SNIPPET_ID');
  </script>
</head>

Replace YOUR_SNIPPET_ID with the ID from your Catchpoint RUM configuration.

Performance impact: The snippet is loaded asynchronously and doesn't block page rendering. The data transmission beacon is fired after the page load event, so it has zero impact on user-perceived performance.

Step 3: Tag Single-Page Applications (SPAs)

For React, Vue, Angular, or other SPA frameworks, route changes don't trigger full page loads. You need to manually signal navigation events to the RUM agent:

React Router example:

import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';

function RUMPageTracker() {
  const location = useLocation();
  
  useEffect(() => {
    if (window._crum && window._crum.newPage) {
      window._crum.newPage(location.pathname);
    }
  }, [location]);
  
  return null;
}

// Add to your root App component
function App() {
  return (
    <Router>
      <RUMPageTracker />
      {/* rest of your app */}
    </Router>
  );
}

Without SPA instrumentation, Catchpoint will only see the initial page load, missing all subsequent navigation.

Step 4: Add Custom Dimensions

Custom dimensions let you segment RUM data by business context:

// Set custom dimensions after the snippet loads
window._crum = window._crum || {};
window._crum.customDimensions = {
  userSegment: 'premium',     // User tier
  appVersion: '2.4.1',        // Deployed version
  experimentGroup: 'variant-b', // A/B test group
  country: 'US'               // If server-side geo is more accurate
};

These dimensions appear as filterable attributes in Catchpoint's RUM dashboard, enabling powerful segmentation analysis.

Key RUM Metrics

Core Web Vitals

Google's Core Web Vitals are the most important user experience metrics from an SEO perspective. Catchpoint captures all three:

Largest Contentful Paint (LCP) Measures when the largest visible element finishes loading. Represents when the main content appears.

  • Good: < 2.5 seconds
  • Needs improvement: 2.5–4 seconds
  • Poor: > 4 seconds

Interaction to Next Paint (INP) Measures responsiveness — how quickly the page responds to user interactions like clicks and taps.

  • Good: < 200 milliseconds
  • Needs improvement: 200–500 ms
  • Poor: > 500 ms

Cumulative Layout Shift (CLS) Measures visual stability — how much content shifts unexpectedly during loading.

  • Good: < 0.1
  • Needs improvement: 0.1–0.25
  • Poor: > 0.25
Metric Description
DNS Resolution Time to resolve the domain name
TCP Connection Time to establish connection
SSL Handshake TLS negotiation time
Time to First Byte (TTFB) Server response time
DOM Interactive DOM parsing complete, scripts executing
DOM Complete All resources loaded
Load Event Page fully loaded

Resource Timing

For each third-party and first-party resource on the page, RUM captures:

  • Resource URL
  • Initiator type (script, image, stylesheet, XHR)
  • Load time
  • Transfer size

This reveals which third-party scripts (analytics, chatbots, ad systems) are causing the most performance impact.

Building RUM Dashboards

Overview Dashboard

Your main RUM dashboard should display:

  1. p75 LCP trend — 75th percentile LCP over the past 30 days
  2. p75 INP — Interaction responsiveness
  3. CLS score — Visual stability
  4. Session volume — Total real user sessions (to contextualize percentages)
  5. Availability — Percentage of sessions with errors

Use p75 (75th percentile) rather than average — averages are pulled down by fast users and don't reflect the experience of slower users.

Page-Level Breakdown

Create a table view showing each page's:

  • URL or page pattern
  • Session count
  • p50 and p75 LCP
  • INP
  • CLS

Sort by session count × (p75 LCP / 2.5). This prioritizes pages that are both high-traffic and slow — where optimization has the most user impact.

Segmentation Views

Build separate views for:

By Device Type Compare desktop vs. mobile vs. tablet performance. Mobile users typically experience 2–3x slower performance.

By Geographic Region Identify which countries have poor performance. If users in Southeast Asia see 6-second LCP while US users see 2 seconds, you need a CDN presence in that region.

By Browser Check if any specific browser version has abnormal performance or error rates.

By Connection Type 4G vs. WiFi vs. 3G shows the impact of network conditions on your real user base.

RUM vs. Synthetic: Reading the Data Together

RUM and synthetic monitoring measure the same thing from different angles. Understanding when they diverge tells you something important:

RUM faster than synthetic

  • Your CDN is serving cached content to users efficiently
  • Real users are geographically closer to your servers than synthetic nodes
  • Users have faster devices than what synthetic emulates

RUM slower than synthetic

  • Real users are on worse networks (mobile, congested ISPs)
  • Third-party scripts are impacting real users but not synthetic tests (ad blockers on synthetic nodes)
  • Real page loads have more user-generated content than the synthetic test URL

Same pattern in both

  • The issue is server-side or in your core assets
  • The geographic distribution of the problem is consistent
  • CDN is not helping real users any more than synthetic

Synthetic catches issues RUM misses

  • New deployments that only affect synthetic test URLs
  • Incidents that resolve within minutes (RUM needs time to accumulate data)
  • Low-traffic pages with insufficient real user data

Performance Optimization Workflow Using RUM Data

Step 1: Identify the Biggest Opportunity

Sort your pages by session count × (p75 LCP − 2.5s). Focus on pages where both traffic and slowness are highest. A checkout page with 50,000 sessions/day at 4.5s LCP is a bigger priority than a blog post with 200 sessions/day at 3s LCP.

Step 2: Segment by Dimension

For the identified page, filter by:

  • Mobile users only (often reveals mobile-specific issues)
  • Specific geographic regions (identifies CDN gaps)
  • Slow connection users (3G, slow 4G)

This narrows the root cause before you start debugging.

Step 3: Check Resource Timing

Look at which resources on the slow-loading pages take the most time for real users. Common culprits:

  • Large, unoptimized images
  • Render-blocking JavaScript
  • Third-party scripts loaded synchronously

Step 4: Make a Change

Implement one optimization at a time:

  • Switch images to WebP/AVIF
  • Add defer or async to non-critical scripts
  • Enable HTTP/3 on your server
  • Adjust CDN caching rules

Step 5: Measure in RUM

After deployment, watch your RUM dashboard for the target page over 48 hours. With sufficient traffic, you'll see a clear shift in p75 LCP distributions if the optimization worked.

Don't rely on synthetic alone to validate — synthetic tests might not reflect the conditions where real users were slow.

Alerting on RUM Data

RUM alerting is fundamentally different from synthetic alerting:

Synthetic: Alert when a test fails or exceeds a threshold (point-in-time) RUM: Alert when a percentile metric degrades over a rolling window

Configure RUM alerts for:

  • p75 LCP exceeds 2.5s over a 1-hour rolling window
  • Error rate exceeds 1% of sessions
  • Any page's session volume drops more than 30% (could indicate availability issue)

Avoid alerting on individual sessions — every user occasionally experiences slowness. Only alert on statistical patterns across many sessions.

Privacy and Compliance Considerations

Catchpoint RUM captures browser timing data, not user content. However, the URL of each page view is collected. For compliance:

GDPR/CCPA considerations:

  • RUM data is performance telemetry, not personal data — but URLs can sometimes contain personal identifiers
  • Use URL masking to strip query parameters: yoursite.com/user/[masked]/profile
  • Review your privacy policy to mention performance monitoring
  • Respect Do Not Track if required by your policy

IP address handling: Catchpoint collects IP addresses for geo-location but (per their data processing agreement) anonymizes or discards them according to your data processing settings.

Cookie-free operation: Catchpoint RUM can operate without cookies, using local storage for session continuity. Verify this matches your cookie consent implementation.

Integrating RUM with Incident Response

The most underused capability of RUM is real-time incident detection. During a production incident:

  1. Open the RUM dashboard on your primary pages
  2. Set the time window to "Last 30 minutes"
  3. Watch error rates and availability — are real users being impacted?
  4. Filter by geography to identify blast radius
  5. Compare current p75 LCP to your baseline to quantify degradation

This gives your incident team real-time user impact data rather than relying solely on server-side metrics that may not reflect the full scope.

Conclusion

Catchpoint RUM transforms performance monitoring from an infrastructure concern into a user experience program. By capturing what real users on real networks actually experience, it reveals gaps that synthetic tests cannot detect and prioritizes optimization work by actual business impact.

The implementation is lightweight — a JavaScript snippet, optional SPA instrumentation, and custom dimensions for your business context. The payoff is visibility into your application's true performance landscape across the diversity of devices, networks, and geographies that make up your actual user base.

For complete application quality assurance, pair Catchpoint's performance monitoring with functional testing using tools like HelpMeTest to ensure that fast pages also do the right things.

Read more

Start now free