RUM, CrUX & Field Data

Introduction

RUM (Real User Monitoring) collects performance metrics from your users in production. CrUX (Chrome User Experience Report) is Google's public aggregation of Chrome real-user metrics — the dataset powering PageSpeed Insights field data and Search Console Core Web Vitals. The Chrome team publishes CrUX methodology on web.dev and Google Cloud docs.

Staff engineers never ship perf fixes validated only in Lighthouse — they triangulate lab, RUM, and CrUX with identical metric definitions.

Business problem

Business pressure: Engineering reported "30% faster" from lab Lighthouse while executives saw Search Console CrUX still Poor — trust gap between teams. Without RUM/CrUX literacy, product ships features that lab greenlights but field data condemns over 28 days.

• Conversion: Segment RUM by device and geography — fixes US desktop lab miss India mobile CrUX reality.
• Compliance: Field data includes assistive tech users on real devices — not just synthetic audits.
• SEO: CrUX is Google's field source of truth for CWV in Search — RUM must align to explain deltas.

Why this feature exists

Platform motivation: Lab cannot replicate full user diversity (cache, extensions, CPU, network). CrUX provides standardized public field dataset; RUM provides site-specific granular attribution CrUX lacks at low traffic.

• History: CrUX launched 2017; BigQuery export; PSI integration; origin + URL level over time.
• Alternative rejected: Synthetic monitoring only — misses long tail devices and real caching behavior.
• Modern role: web-vitals.js + analytics is industry RUM pattern; CrUX History API for trends.

Browser internals

Inside the engine: Chrome collects eligible metrics from opted-in users meeting privacy thresholds (minimum page views). UKM pipeline aggregates to CrUX. Your RUM uses same PerformanceObserver APIs in page context — LCP, INP, CLS, TTFB, FCP via web-vitals library maintained by Google.

• CrUX privacy: 28-day rolling; k-anonymity thresholds for URL-level data.
• RUM collection: beacon on load + visibility change; avoid double-counting SPA navigations.
• Attribution: LCP element selector, INP interaction target — RUM can capture, CrUX aggregates only.
• Not in CrUX: Custom timers; server-side only metrics; non-Chrome browsers (use RUM to supplement).

Data sources triangle

Lab (Lighthouse)
  → controlled, reproducible, CI-friendly
  → misses field variance

RUM (your analytics + web-vitals.js)
  → full browser mix, custom dimensions
  → you own pipeline cost

CrUX (Google public dataset)
  → Chrome users, standardized CWV
  → Search Console + PSI field section
  → 28-day lag, origin/URL p75

Rendering workflow

Rendering path: Field metrics reflect real rendering pipeline on real devices — thermal throttling, memory pressure, concurrent apps. Lab desktop cable throttling underestimates main-thread congestion that CrUX INP captures.

• Critical path: Cold vs warm cache in CrUX — repeat visitors faster LCP.
• Layout: Field CLS from ads/fonts users actually see — not stubbed in lab.
• Composite: Low-end GPU differences invisible in lab MacBook traces.

Feature deep dive

Triangulation workflow: (1) CrUX/Search Console for executive CWV status; (2) RUM for URL/template/device breakdown; (3) Lighthouse lab in CI for regression prevention. Use same thresholds as web.dev vitals definitions.

• CrUX API: PageSpeed Insights API, CrUX History API, BigQuery export for analysts.
• web-vitals.js: Official library — onLCP, onINP, onCLS with attribution build.
• Segmentation: RUM dimensions: country, device, connection, page template, A/B bucket.
• SPA: Soft navigations need separate RUM instrumentation — CrUX treats full page load primarily.

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

function sendToAnalytics({ name, value, id, attribution }) {
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_value: value,
    metric_delta: attribution,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Accessibility analysis

A11y architecture: RUM can segment by reduced-motion preference and screen reader detection (heuristic) — CrUX does not expose this. Field perf for a11y users often worse on older devices — RUM responsibility.

• Screen readers: Include in RUM device/browser dimensions — NVDA/JAWS on Windows underrepresented in lab.
• Keyboard: RUM cannot measure keyboard-only INP separately without custom instrumentation.
• WCAG: Field data complements automated axe — real user pain metric.

SEO impact

SEO architecture: Search Console CWV report sourced from CrUX. SEO team needs CrUX literacy — not vendor synthetic score. URL-level CrUX requires sufficient traffic; small sites use origin-level only.

• Crawl: CrUX unrelated to crawl budget directly.
• Rich results: Indirect — fast pages retain impressions.
• Core Web Vitals: CrUX p75 is the SEO-facing measurement — RUM explains how to fix it.

Security considerations

Security boundary: RUM beacons exfiltrate URLs and metrics — avoid leaking PII in query params. CrUX is aggregated public data — no PII. Govern RUM third-party scripts under same CSP as analytics.

• XSS: Compromised RUM snippet steals user paths — integrity hash scripts.
• CSP: connect-src must allow RUM endpoint.
• Clickjacking: N/A to measurement pipeline.

Performance impact

Performance: web-vitals.js is lightweight (~2KB) — INP observer has overhead but negligible vs site JS. Do not block render for RUM — sendBeacon on idle. CrUX collection is browser-internal — zero site cost.

• LCP: RUM LCP attribution identifies element — faster fix cycle than CrUX alone.
• INP: RUM captures interaction target selector for worst INP events.
• CLS: RUM + Layout Instability attribution links shift to DOM node.

Real production example

Production pattern: Etsy and major retailers pipe web-vitals to internal dashboards overlaid on CrUX BigQuery export. Weekly perf review: CrUX p75 trend + RUM regression bisect + Lighthouse CI diff — trio recommended in Chrome DevRel observability talks.

• Pattern: GA4 + web-vitals attribution; alert if RUM LCP p75 degrades 10% week-over-week.
• Monitoring: Search Console + PSI API automated weekly scrape to data warehouse.
• Fix: RUM showed INP Poor only on Android WebView — embedded app fix, lab missed it.

Enterprise usage

Enterprise: Data platform teams ingest CrUX BigQuery into Looker; product teams own RUM dashboards; platform teams own Lighthouse CI — three stakeholders, one metric dictionary from web.dev.

• Design system: Component perf budgets validated in RUM by component flag dimension.
• CMS: Template ID in RUM payload — attribute CLS to template.
• CI gates: Lab regression blocks merge; CrUX validates post-deploy in 28-day window.

Common production failures

What breaks in prod: RUM used custom FID metric while Search Console switched to INP — false "we're Good" for six months. Metric dictionary drift between RUM vendor and CrUX.

• Incident: RUM sampled 1% — missed CLS regression affecting majority until CrUX updated.
• SEO regression: CrUX Poor detected before internal dashboards — no CrUX monitoring wired.
• Perf regression: Double-firing RUM beacons inflated averages — wrong prioritization.

Architecture review questions

• Do RUM metrics match web.dev/CrUX definitions (LCP, INP, CLS)?
• Is CrUX History API or Search Console monitored weekly?
• Can we segment RUM by template, country, and device class?
• What is minimum traffic for URL-level CrUX on key pages?
• Is web-vitals.js using attribution build for debugging?
• Lab vs RUM vs CrUX gap documented for top URLs?

Hands-on project

Project: Query CrUX via PageSpeed Insights API for your origin. Implement web-vitals.js in local demo page logging to console. Compare metric names, values, and thresholds to web.dev documentation.

• Deliverable: CrUX JSON snapshot + RUM console screenshot + triangulation doc.
• Verify: Google CrUX documentation; web-vitals GitHub README.
• Stretch: BigQuery CrUX sample query for 28-day LCP trend.

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

RUM and CrUX provide real-user performance data complementing lab Lighthouse. The Chrome team maintains CrUX and web-vitals.js; production teams triangulate both with web.dev thresholds to fix HTML and rendering issues that field users experience.