Real User Monitoring & Performance Budgets

Real User Monitoring and Performance Budgets

A Lighthouse score on a developer's fast laptop says little about how a page feels on a mid-range phone over a congested mobile network. Real user monitoring (RUM) measures performance in the browsers of actual visitors — every device, network, location, and page — and turns that into distributions you can track. Performance budgets are the guardrails that keep those numbers from drifting: agreed limits on metrics and resources, checked in CI and watched in production.

Together they close the loop. Lab tests in CI catch regressions before release; RUM confirms what users actually experience and catches what lab tests cannot, such as slow third-party scripts, specific devices, and real interaction patterns.

TL;DR

Lab data (Lighthouse, WebPageTest) is controlled and repeatable; field data (RUM, CrUX) reflects real users. You need both.
Collect LCP, INP, and CLS with the web-vitals library and send them with navigator.sendBeacon.
Report the 75th percentile, segmented by page type, device class, and connection — averages hide pain.
Use attribution data to learn which element, script, or interaction caused a slow metric.
Set budgets on user-centric metrics (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1) and resources (JavaScript size, requests).
Enforce budgets in CI (Lighthouse CI, bundle size limits) and alert on field regressions after release.

Quick Example

Collect Core Web Vitals from real users and send them to your own endpoint:

And a lab budget enforced on every pull request with Lighthouse CI:

Core Concepts

Lab Versus Field

Interaction to Next Paint (INP) in particular can only be measured meaningfully in the field, because it depends on real user interactions throughout a visit. Lab tools use Total Blocking Time as a proxy.

The Metrics

See Core Web Vitals for how each metric is defined and improved.

Percentiles and Segmentation

Performance is a distribution. Report the 75th percentile (the Core Web Vitals convention) and often the 95th, and split by:

Page type or route — product pages and checkout behave differently.
Device class — low-end Android phones are where performance problems live.
Connection type and country — network conditions dominate loading metrics.
Navigation type — back/forward cache restores and prerendered pages are much faster than cold loads.
Release version — to tie regressions to deploys.

Attribution

A slow p75 LCP tells you something is wrong; attribution tells you what. The web-vitals/attribution build reports the LCP element and its loading phases (TTFB, resource load delay, load time, render delay), the INP interaction target and its input delay, processing, and presentation times, and the element responsible for the largest layout shift. The Long Animation Frames API identifies scripts behind slow interactions, including third parties.

Performance Budgets

Types of Budgets

Resource budgets are the most actionable in pull requests, because they fail precisely when someone adds a large dependency. Metric budgets are the ones users feel.

Enforcing Budgets

Pull requests: bundle size limits (size-limit or a custom check), Lighthouse CI assertions on representative pages, and bundle diff comments.
Release monitoring: compare field p75 per page type before and after each deploy; alert when a budget is crossed for a sustained period.
Ownership: each budget has an owner and a documented response — revert, fix forward, or consciously raise the budget with a reason.

Privacy and Data Volume

Sample high-traffic sites (for example 10–25% of sessions) while keeping enough data for low-traffic pages.
Avoid personal data: send page types instead of full URLs with query strings, and never include user identifiers you do not need.
Respect consent requirements where RUM data is processed by third parties.
Aggregate early: store percentiles and histograms per segment rather than raw events forever.

Best Practices

Budget What Users Feel, Gate What Developers Change

Track user-centric metrics in the field, and gate pull requests on the resource budgets that drive them.

Watch Low-End Devices First

Segment by device memory or class, and set goals for the slowest common devices — not the median laptop.

Tie Metrics to Releases

Tag RUM data with release versions so a regression points to a deploy, and use feature flags to isolate the change that caused it.

Include Third Parties in Budgets

Tag managers, chat widgets, and analytics often dominate main-thread time. Measure them like your own code and hold vendors to budgets.

Common Mistakes

Reporting Averages

Lab Scores as the Only Signal

Budgets Nobody Owns

FAQ

What is real user monitoring?

Collecting performance measurements from real visitors' browsers — such as Core Web Vitals, navigation timings, and errors — and aggregating them to understand the experience across devices, networks, and pages.

What is the difference between RUM and synthetic monitoring?

Synthetic monitoring runs scripted page loads in controlled environments, which is repeatable and works before release. RUM measures what actual users experience, including real devices, networks, and interactions. Each catches problems the other misses.

What is a performance budget?

An agreed limit on a performance metric or resource — such as LCP under 2.5 seconds or initial JavaScript under 180 KB — that a team checks automatically and treats as a release criterion.

Why use the 75th percentile?

It represents the experience of most users while being less noisy than the extremes. Core Web Vitals assessments use the 75th percentile of page loads, segmented by mobile and desktop.

Can I measure INP in the lab?

Not fully. INP depends on real interactions during a visit. Lab tools approximate responsiveness with Total Blocking Time, and scripted interactions can help debug, but field data is the source of truth.