Real user monitoring with Core Web Vitals and backend traces

What is real user monitoring?

Real user monitoring (RUM) measures the performance and reliability of a web application as experienced by actual users in their own browsers. A small JavaScript agent records page loads, route changes, user interactions, network requests and errors, and sends them to an observability backend. Unlike lab tests, RUM captures the full diversity of real conditions: slow mobile networks, older devices, browser extensions, distant regions and unusual navigation paths.

RUM is a form of passive monitoring. It only reports what users actually did, which makes it the most accurate source for questions like "How fast is our checkout for customers in Brazil on Android?" It complements synthetic monitoring, which proactively tests availability even when no users are active.

Why real user monitoring matters

Backend dashboards can look perfectly healthy while users suffer. A large JavaScript bundle, a slow third-party script, a layout shift caused by a late-loading banner or a CDN issue in one region never appear in server metrics. RUM shows the experience from the only perspective that ultimately counts.

• Search visibility: Core Web Vitals are part of Google's page experience signals, and field data from real users is what counts.
• Conversion: slow and unstable pages lead to abandoned sessions. RUM lets you segment performance by funnel step.
• Faster debugging: frontend errors arrive with browser, OS, release and the user's path, instead of vague support tickets.
• Release confidence: compare performance before and after a frontend deployment with real traffic.

Core Web Vitals and other key RUM metrics

Metric	What it measures	Good threshold (p75)
Largest Contentful Paint (LCP)	Loading: when the main content becomes visible	2.5 s or less
Interaction to Next Paint (INP)	Responsiveness: delay between interaction and visual response	200 ms or less
Cumulative Layout Shift (CLS)	Visual stability: unexpected layout movement	0.1 or less

Google evaluates Core Web Vitals at the 75th percentile of page views. Beyond these three, useful RUM signals include Time to First Byte, First Contentful Paint, long tasks, resource timing for scripts, images and API calls, JavaScript error rate and Apdex-style satisfaction scores. Always look at distributions and percentiles rather than averages, because a fast majority can hide a large group of frustrated users.

Real user monitoring with Obseria

The Obseria RUM agent captures Core Web Vitals, navigation and resource timing, single-page-app route changes, user actions and JavaScript errors. It injects W3C Trace Context headers into fetch and XHR requests, so each frontend request is connected to its distributed trace in the backend. When a page is slow, you can see whether the time was spent in the browser, on the network or in a specific backend service.

RUM events land in Obseria Lake alongside traces, logs and metrics. Obseria Pipeline masks personal data such as email addresses or IDs in URLs before storage. You can segment by any attribute, including page, country, browser, release or customer plan, and query with OQL, for example fetch rum.events | filter page == "/checkout" | summarize p75(lcp), by:{country}. JavaScript errors appear in the Errors Inbox, and every session links to its session replay. RUM web events are billed at $0.060 per million ingested and $0.540 per million stored.

Best practices for real user monitoring

1. Load the agent early in the page so that it captures the full page load and early errors.
2. Tag releases and environments to compare frontend versions and keep staging traffic separate.
3. Upload source maps from CI so JavaScript errors are readable.
4. Set SLOs on user experience, such as p75 LCP on key pages, instead of only on backend latency.
5. Segment before you optimize. A global average hides problems that affect specific devices, countries or pages.
6. Respect privacy: collect only what you need, mask personal data at ingest and honor consent requirements.