INP-era replication framework + divergence taxonomy

When does lab predict field?

A green Lighthouse score and a passing Core Web Vitals grade are not the same thing — and the gap between them isn't random noise. We reframe the lab-versus-field question as a transportability problem: a lab result predicts a field outcome only when the measured URL, device, navigation state, geography, time window and performance mechanism match the real users CrUX summarises. When they don't, the disagreement itself tells you which mechanism failed.

What this is

A research-grade framework and an executable design — pre-analysis plan, data model, divergence taxonomy and a runnable reproducibility kit (BigQuery templates, a deterministic classifier, a calibration-first modelling protocol) over public CrUX and HTTP Archive / Lighthouse. It reports verified public facts and does not invent a headline correlation for a BigQuery run nobody has executed yet. The contribution is the method that turns lab-field disagreement from a nuisance into a diagnosis.

The problem: a high score is not a pass

The starting evidence is now five years old and still unbeaten as a baseline. In 2021 Brendan Kenny joined Lighthouse and CrUX at HTTP Archive scale and found that a high Lighthouse score raises the probability of passing Core Web Vitals but does not guarantee it — 43% of pages scoring 90 or above failed at least one Core Web Vital. Philip Walton turned that into a challenge to the whole field: lab tools are useful, but they have blind spots and cannot be treated as equivalent to real-user data.

Two stacked bars from Kenny 2021. Among Lighthouse 90+ pages, 57% passed all CWV and 43% failed at least one; restricted to pages with a proper mobile viewport, 71% passed and 29% failed. Of the failures, 46.6% missed only FID, 30.8% only LCP, 8.9% only CLS. Measured in the FID era.
Figure 1 — A 90+ Lighthouse score is not a CWV pass (Kenny, 2021). And this is the optimistic baseline: it was measured in the FID era, before INP made responsiveness harder to predict from a load-time lab run.
18.4Morigins in CrUX (May 2026)
55.9%pass all three Core Web Vitals
68.6%good LCP — the worst-passing metric, mostly a field/server story
86.6%good INP — best-passing, yet hardest to see in the lab
CrUX May 2026 pass rates across 18.4 million origins: all three Core Web Vitals 55.9%, good LCP 68.6% (the lowest, the bottleneck), good CLS 81.3%, good INP 86.6% (the highest).
Figure 2 — Where the web actually sits (CrUX, May 2026). LCP is the binding constraint on the all-three pass rate; INP passes most often in aggregate — which is exactly why a green lab run is most likely to miss the sites that do have an INP problem.

Why the gap reopened with INP

In March 2024, Interaction to Next Paint replaced First Input Delay as the responsiveness Core Web Vital. FID measured only the delay before the first interaction was handled — a quantity a load-time tool can approximate. INP measures the full interaction lifecycle — input delay, processing and presentation — across every interaction in the session: menu opens, search, filters, carousels, checkout, cookie banners, ad callbacks.

Here's the structural problem. Lighthouse has no INP measurement. Its only responsiveness signal is Total Blocking Time — a load-time, main-thread-blocking proxy that carries 30% of the performance score. But TBT measures work during page load, while INP is set by work that happens after load, when the user interacts. The two can disagree in both directions, and the May-2026 CrUX numbers sharpen the point: INP is the best-passing CWV in aggregate (86.6% good), yet it's the one the lab is structurally worst at predicting — so when a site does have an INP problem, a green lab run is most likely to miss it.

Lab predicts field only when four gates hold

The method is to stop asking “is the lab right?” and instead ask “does this lab measurement transport to the CrUX population?” That holds only when four gates are all satisfied. Pass them, and the lab metric should track the field metric tightly. Fail one, and the residual is a named divergence class — a diagnosis, not noise.

Four sequential gates: population, navigation mode, mechanism, and time and geography. Passing all four means the lab metric is expected to predict the field metric. Failing each maps to specific divergence classes: page-mix/device-mix, bfcache/service-worker, INP-behaviour/TTFB-field/field-CLS, and temporal-window/geographic.
Figure 3 — The four transportability gates. CrUX added navigation-type fractions precisely because cold loads, reloads, bfcache restores and prerenders perform differently even on an unchanged site — which is why “navigation mode” is its own gate.

The divergence taxonomy

When a gate fails, the lab-field pattern falls into one of twelve classes. The taxonomy is built to be falsifiable and machine-readable: a class is assigned only when a specific lab-field pattern, an observable diagnostic, and a minimum evidence standard are all met — never because it sounds plausible. The most important case in the INP era is the top-right cell below: the lab looks fine and real users don't.

A two-by-two matrix of lab TBT (rows) versus field INP (columns). Both good is representative convergence; lab good but field poor is INP-behaviour divergence (the dangerous cell); lab poor but field good is a lab-only false alarm; both poor is representative. The lab predicts the field on the agreeing diagonal.
Figure 4 — The INP slice of the taxonomy. On the agreeing diagonal the lab transports; off it, it misleads — and in opposite directions. Top-right is false confidence (ship a regression); bottom-left is false alarm (waste a rewrite).
The full 12-class lab-field divergence taxonomy. The machine-readable version (with diagnostics and evidence standards) ships in the kit as divergence_taxonomy.csv.
ClassLab → field patternKey diagnosticFirst response
RepresentativeBoth pass or both fail, within toleranceLow page-mix entropy; cold nav dominant; stable TTFB/RTTIterate in the lab; keep monitoring the field
TTFB-fieldLab LCP good, field LCP poorPoor CrUX TTFB/RTT; cache-miss signatures; geo varianceSegment TTFB by country; fix the server path before image micro-optimisation
INP-behaviourLab TBT good, field INP poorLow TBT but poor CrUX INP; hydration; interaction-heavy templatesMeasure INP attribution in RUM; reduce long tasks near real interactions
TBT false alarmLab TBT poor, field INP goodHigh TBT; good INP; late first interaction; low interaction rateDon't ship a score-driven rewrite; keep an INP guardrail
CLS lab-onlyLab CLS poor, field CLS goodLab filmstrip shift; consent/viewport/cookie-state mismatchReplay consent and viewport states; reserve space only for real field shifts
CLS field-onlyLab CLS good, field CLS poorLate ads, embeds, personalisation, font swaps, injected contentCollect layout-shift attribution; reserve slots; constrain embeds
bfcache / SWCold lab disagrees with warm field (either direction)High back/forward-cache, reload or prerender navigation shareRun cold and warm profiles; inspect navigation_types
Geo / RTTSingle-region lab disagrees with fieldLarge country mix; high RTT p75; CDN region gapsWeight lab geographies by CrUX traffic; test high-volume poor countries
Device mixLab device profile disagrees with fieldCPU-sensitive JS; field hardware distribution differsUse a low/mid/high device matrix; prioritise field RUM by device class
Page mixHomepage lab disagrees with origin-level CrUXMany high-traffic templates; homepage low-traffic; SPA routesBuild a template-weighted lab sample; avoid homepage-only claims
Time windowCurrent lab disagrees with the 28-day field windowRecent deploy/incident; CrUX rolling-window inertiaAlign by date; use RUM now; forecast the next CrUX windows
Content varianceHigh lab-run variance; inconsistent field segmentsA/B tests, consent, ads, personalisation, logged-in stateRecord variants; stratify; repeat lab n ≥ 9; report uncertainty

Three estimands you must not conflate

Most lab-vs-field arguments are confused because they mix three different questions, each needing a different evidence tier. Keeping them apart is half the discipline:

  1. Contemporaneous agreement

    Does today's lab result match the current CrUX window? This is a concordance analysis, not a forecast — same-month CrUX already reflects the past 28 days, so it can't cleanly “predict” anything. Lab-only is the right evidence tier.

  2. Prospective prediction

    Will this origin pass CrUX next window? This needs lagged panels and public field-context features (TTFB, RTT, navigation-type fractions) — tier two: lab plus public reconciliation.

  3. Causal remediation

    Did a specific fix cause the field metric to move? Only owner RUM attribution and an event study can answer this — tier three. A lab delta alone never establishes it.

The three-tier evidence model maps directly onto these: lab-only for rapid iteration and concordance, lab + public field context for calibrated prospective prediction, and RUM-audited intervention for causal claims. Treating a tier-one signal as tier-three evidence is exactly how teams ship a “fix” that the field never feels.

A rising staircase of three evidence tiers: tier 1 lab-only answers contemporaneous agreement; tier 2 lab plus public field context (CrUX TTFB, RTT, navigation-type fractions, lagged panels) answers prospective prediction; tier 3 RUM-audited intervention with an event study answers causal remediation and is the only causal tier.
Figure 5 — The three-tier evidence model, mapped to the three estimands. Each step up adds evidence and unlocks a stronger claim; a tier-1 lab signal can never carry a tier-3 causal conclusion.

The study design (built to survive review)

The executable design predicts a calibrated probability that an origin passes CrUX CWV, plus metric-specific p75 estimates and divergence-class probabilities, from four nested models:

  • Model A — Lighthouse score only (the naïve baseline everyone uses).
  • Model B — lab metrics separately: lab LCP, TBT, CLS, FCP, Speed Index, bytes.
  • Model C — adds public field context: CrUX TTFB, RTT, navigation-type fractions, LCP resource type, form factor, month, HTTP Archive technology/request features.
  • Model D — adds repeated lab runs and, where available, owner RUM attribution.

The headline isn't whether C beats B on accuracy — it's where and why calibration improves. Evaluation is therefore calibration-first: Brier score, expected calibration error, calibration slope/intercept and conformal-interval coverage alongside AUROC/AUPRC — because a model with great ranking but poor calibration misprices risk and still drives wrong decisions. And validation is blocked, never random: random row splits leak origin identity and temporal structure. The protocol uses origin-blocked, time-blocked and technology-segment holdouts, with the split pre-registered before outcomes are seen.

The reconciliation playbook

The point of all this is operational: no team should burn weeks optimising the wrong proxy when the disagreement already indicates the failure mechanism. Read your lab-field pattern off the taxonomy, and the first move is determined:

Limitations

  1. CrUX is a population, not a census

    CrUX reports eligible Chrome users meeting traffic thresholds — not all browsers, and not low-traffic origins. Conclusions generalise to the CrUX-eligible public web, the stated target population.

  2. Origin aggregation hides pages

    CrUX origin units blend many templates; a single lab URL is one page. The design reports page-level and origin-level estimands separately and refuses homepage-only origin claims.

  3. Same-month is concordance, not forecast

    A same-window lab-vs-CrUX comparison can't be a clean prediction — the field window already happened. Prospective claims require lagged panels, kept distinct here on purpose.

  4. No fabricated coefficients

    This release is the framework, taxonomy and protocol; it does not report a fitted million-origin model. The kit is built to produce one — and to be audited when it does.

Data, code & sources

Published under CC BY 4.0: the divergence taxonomy and feature dictionary, the BigQuery panel templates, a deterministic divergence classifier, the calibration-first modelling protocol and the pre-analysis plan — everything needed to run the study over public CrUX and HTTP Archive.

Browse the artefacts

Key sources

Cite this study

PageSpeedAudit Research (2026). When does lab predict field? An INP-era
replication framework, divergence taxonomy, and calibrated reconciliation
protocol for Lighthouse and CrUX.
https://pagespeedaudit.com/research/when-does-lab-predict-field

@misc{pagespeedaudit2026labfield,
  title  = {When does lab predict field? An INP-era replication framework,
            divergence taxonomy, and calibrated reconciliation protocol},
  author = {{PageSpeedAudit Research}},
  year   = {2026},
  url    = {https://pagespeedaudit.com/research/when-does-lab-predict-field},
  note   = {Taxonomy + reproducibility kit, CC BY 4.0}
}

Stuck between a green score and a failing grade?

A PageSpeedAudit report reads your lab and your CrUX field data together, classifies the divergence, and tells you which mechanism is actually failing — so you fix the server path, the post-load interaction or the page mix, not whichever proxy the score happened to flag. See the sister studies “Do Lighthouse's promised savings materialize?” and “How many Lighthouse runs prove a change?”