RUM and field profiling: lab lies, the field decides

Lab lies, field decides

A Lighthouse run on your machine is a single sample from a hardware distribution your users do not inhabit. The median user device has a CPU several times slower than a developer laptop; the field adds throttled networks, 4GB-RAM phones, battery-saver mode, twenty open tabs, ad-blockers, and sessions that last eight hours instead of the lab’s ninety seconds. Lab tooling (Lighthouse, WebPageTest, your local Profiler) remains essential — it is controlled, so it can detect regressions pre-release on a fixed device and reproduce them deterministically. But it answers “can this be slow?” never “is this slow for real users?”. Field data — Real User Monitoring — is the ground truth the Core Web Vitals program is built on: Chrome aggregates real-session LCP, INP, and CLS per origin, and the passing bar is p75 of real page views. A senior team runs both and never confuses their roles: lab as the pre-release regression gate, field as the verdict. When you find yourself arguing with field data using a Lighthouse score, that is the confusion this lesson is designed to prevent.

Wiring web-vitals: three dimensions or noise

The web-vitals library is the standard instrument: onLCP, onINP, onCLS callbacks fire when a metric finalizes — which for INP and CLS is late in the page lifecycle, so reporting must flush on visibilitychange/pagehide via sendBeacon, not on load. The wiring is twenty lines; what makes the data actionable is the dimensions you attach:

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metric.name,            // 'INP' | 'LCP' | 'CLS'
    value: metric.value,
    rating: metric.rating,        // 'good' | 'needs-improvement' | 'poor'
    route: routePattern(),        // dimension 1: '/orders/:id', NOT the raw URL
    release: __RELEASE__,         // dimension 2: build id injected at deploy
    device: deviceClass(),        // dimension 3: coarse bucket, e.g. memory + cores
    attr: summarize(metric.attribution),
  }));
}
onINP(send); onLCP(send); onCLS(send);

Route tells you which surface regressed — a global number averages your marketing page with your data grid into meaninglessness. Release turns “it got slow sometime” into “ring N is 40% worse than ring N−1” — the regressed-release question becomes a single group-by. Device class separates “we shipped a regression” from “a retail campaign brought in low-end Android traffic” — a traffic-mix shift moves global percentiles with zero code change. Missing any one of the three collapses distinct populations into an average that cannot answer questions; this is exactly the three-week hunt from the Hook.

INP attribution: where the milliseconds went

INP is roughly the worst interaction of the page view (for busy pages, a high percentile of all interactions — so one bad click among hundreds still counts). The attribution build splits each candidate interaction into three phases, and the split decides where you work: input delay — the event sat in the queue because the main thread was busy with something else (hydration, a chart update, third-party script); processing duration — your handlers ran, including the synchronous React render and commit they trigger; presentation delay — the frame after handlers took long (layout, paint, too much DOM). Attribution also names the interaction target element and event type. The React-specific reading: a fat processing slice on keystrokes is usually a large synchronous render cascade — the fixes are memoization, list virtualization, or moving the update into a transition. A fat input delay on clicks right after navigation is usually hydration or data parsing hogging the thread — handler optimization does nothing there. Long Tasks and the newer Long Animation Frames observer (PerformanceObserver with type long-animation-frame) attribute the busy thread to scripts, closing the loop on “busy with what?”.

The React Profiler in production, sampled

The Profiler component’s onRender callback reports per-commit timings: id, phase (mount/update), actualDuration (time spent rendering the subtree this commit), baseDuration (estimated full-render cost without memoization). Production builds strip profiling by default; opting in means shipping the profiling build (react-dom/profiling), which adds a few percent overhead. The discipline that makes this viable: sample sessions, not commits — enable profiling for ~1% of sessions chosen at session start, beacon aggregated actualDuration per Profiler id, and keep every session’s data tagged with the same three dimensions. Full tracing on every session is too heavy twice over: the runtime overhead lands on exactly the slow devices you care about, and the beacon volume costs more than the insight. One percent of millions of sessions yields tight percentile estimates per release ring — enough to see that OrdersTable commits got 3× slower in release 142 without profiling a single extra user.

Percentiles per ring, alerts on impact, and the privacy line

The query that answers “which release regressed” is: p75 INP per route, grouped by release ring, compared ring-over-ring — canary at 1% gives you the answer before full rollout if traffic clears the minimum sample size. Alert design follows one principle: page on user impact, not on metrics. A page-worthy alert is a conjunction — route p75 above threshold AND sustained for N minutes AND traffic above a floor — because any single condition alone produces noise: percentiles on thin traffic swing wildly, transient spikes self-heal, and one slow synthetic probe is not an incident. Soft drift (p75 creeping 5% per week) goes to a weekly review channel, not the pager. And the privacy line is non-negotiable: performance beacons carry no PII — route patterns instead of raw URLs (querystrings leak tokens and emails), coarse device buckets instead of fingerprints, no user ids. A perf beacon that can identify a user is a data-protection incident waiting for an auditor; design the schema so the question never arises.