INP yield-gaming audit + registered design
Earlier paint, or less work?
Since Interaction to Next Paint became a Core Web Vital in March 2024, mobile INP has improved across the web. But over the same window, lab-measured Total Blocking Time rose 58%. Both can be true at once — and that's the problem. A page can lower INP by doing less work, or by yielding: repainting sooner and finishing the same work later. INP can't tell them apart. This audit can.
What this is
A research-grade framework and an executable design — definitions, estimands, a registered analysis plan and a runnable kit (HTTP Archive + CrUX SQL, a yield-pattern detector codebook, field RUM instrumentation, a Playwright lab-replay harness, a micro-UX spec). It reports verified public facts and deliberately does not invent a global “yield-only share” for a BigQuery-scale run nobody has executed yet — because that number cannot be inferred from CrUX alone. The contribution is the method that makes the earlier-paint-versus-less-work question measurable instead of rhetorical.
The paradox: responsiveness up, blocking up
Here is the fact that started this. The 2025 Web Almanac reports that mobile good-INP coverage rose from 74% to 77% year over year, and the top 1,000 sites jumped from 53% to 63%. Real users, in the field, experienced more responsive pages. Yet the same chapter reports that median mobile Total Blocking Time grew 58% — from 1,209 ms to 1,916 ms. In the lab, the main thread got more congested, not less.
TBT divergence is a signal, not a verdict — TBT is a load-time, lab proxy and INP is an interaction-time, field metric, so they can drift apart for several innocent reasons (faster field devices, a different page mix, heavier background work that never touches an interaction). But one of the candidate explanations is exactly the one that matters for metric integrity: work didn't shrink, it moved — deferred past the first paint, out of INP's measured window. The web now has enough public evidence to test that directly, and enough reason to.
What INP measures — and where it stops
INP measures the latency from a user interaction to the next paint that follows it, reported at roughly the worst interaction of the visit, with a “good” bar of 200 ms at the 75th percentile. It decomposes into input delay, processing duration and presentation delay. It is a genuinely good metric: it captures the speed of visible response from real users. But it has a boundary by design — the first visible response is not the same thing as the task being done.
That boundary is the whole game. A handler can paint something at 100 ms and finish the real work at 350 ms. Whether that's a gift or a trick depends entirely on what it painted:
INP rewards the second and third rows equally — both repaint fast — even though only the second helps. That gap between metric and task is what an audit has to measure, because the metric alone is blind to it.
Yielding is a real tool — not a hack
Start from the steelman: breaking a long task so the browser can paint and accept input between chunks is
good engineering. scheduler.yield() exists precisely to make this principled —
unlike a bare setTimeout(…, 0), its continuation keeps priority. The Web Vitals team has said
plainly that wrapping work in a timer to paint sooner is not automatically a hack. So this
audit is not a hunt for villains. It's a measurement discipline.
What makes the question population-scale is that the biggest yield adopters aren't individual sites — they're third-party libraries on millions of origins, and the changes are documented in public:
| Intervention | What changed | Reported effect | Work / completion measured? |
|---|---|---|---|
| GPT (Google Publisher Tag) | Yields the JS thread on out-of-viewport ad insertion (threadYield) | Mobile INP pass rate for GPT origins 55.58% → 66.12% | No |
| CMPs (OneTrust, Complianz, Axeptio…) | Consent flows yield more often, especially once cookies are accepted | Direction positive (not separately quantified) | No |
| Prebid (v10+) | Yields the main thread while processing its command queue | “More responsive… improving INP” (documented) | No |
The GPT number is the sharpest public anchor — a +10.5-point mobile pass-rate move attributed to a yield change, reported in Chrome's own CrUX release notes. It proves yield adoption can move INP at scale. It says nothing about whether those ad-heavy pages did less work, or whether anything completed sooner — because no one measured that. That missing half is the audit.
Defining the line: outcome, not intent
You cannot audit “gaming” by guessing what a developer meant. So the definition is outcome-based and falsifiable. Take any change that improves INP by at least 20 ms (or 10%), measure its total interaction work and its task completion against a controlled counterfactual, and the verdict follows mechanically:
| Class | When (vs. counterfactual) | Verdict |
|---|---|---|
| Work-reducing | INP↓, total work ↓ ≥5%, no completion harm | A real fix — ship it |
| Yield-only, beneficial | INP↓, work within ±5%, completion or control improves | Keep — real feedback, sooner |
| Yield-only, neutral | INP↓, work within ±5%, completion unchanged | Metric moved, UX didn't |
| Yield-shifting, harmful | INP↓ but work ↑ ≥5%, or completion worse, or next interaction delayed | “Gaming” — work hidden, not removed |
| No detectable effect | |ΔINP| under 20 ms / 10% | Nothing happened |
Crucially, the definition permits legitimate yielding. Painting a pressed button or a real pending state at 100 ms and finishing at 350 ms is beneficial, not gaming. The line is crossed only when the work grows, the task slows, or the cost is simply pushed into the user's next tap.
Four questions you must not conflate
The audit decomposes one headline question — how much 2024–2026 INP improvement repaints sooner without doing less, and does it help users? — into four estimands, each needing a different kind of evidence. Mixing them is the field's most common mistake:
E1 — Adoption → INP
Among origins seen in both HTTP Archive and CrUX, what happens to good-INP share and p75 INP when an origin first adopts a yield pattern, net of origin and month fixed effects? This is the only estimand CrUX can help answer — and even then only paired with HTTP Archive's code-adoption signal.
E2 — Yield-only share
Of all the INP improvement we can replay, how much comes from changes that repaint sooner without reducing total work? This is the number everyone wants to quote — and the one CrUX cannot give you.
E3 — Work-reduction share
The complement: how much of the improvement comes from genuinely doing less main-thread work? E2 and E3 together partition the win.
E4 — Task-completion impact
When a yield-only change improves INP, does the task actually finish faster, succeed more often, and feel more in control — or did only the proxy move? This is the rung that decides whether any of it mattered.
E1 is a population/causal estimate. E2–E4 are mechanism and user-value estimands that require controlled traces and task-level data. Treating a field metric movement (E1) as proof of user benefit (E4) is precisely how a team ships a “win” the field never feels.
The design: triangulate four sources
No single dataset can separate earlier paint from less work. CrUX has the field outcome but no trace of post-interaction work. HTTP Archive has the code but not the user experience. So the design joins four sources, and each estimand draws only on the ones that can actually identify it:
- Study 1 — script corpus × CrUX. Detect yield patterns in HTTP Archive response bodies, join to CrUX origin-months, and run an event study around first adoption (origin + month fixed effects), plus a vendor difference-in-differences around the documented GPT and CMP rollout windows. Answers E1.
- Study 2 — lab replay. Re-run real adopter pages with yield intact versus a no-yield counterfactual (
threadYield:"DISABLED",pbjs.yield=false, in-handler execution), measuring total work, completion and carryover delay. Answers E2 and E3. - Study 3 — micro-UX. Controlled pages with identical work isolate semantic-yield vs cosmetic-yield vs blocking, measuring completion time, success, and perceived control. Answers E4.
A two-level detector keeps Study 1 honest: a high-recall lexical scan finds candidate patterns, then an
AST/context classifier decides whether a timer is actually interaction-adjacent — because most
setTimeout calls are analytics, polling or animation, not yielding. No origin-level number
is published before a stratified manual validation reports precision, recall and inter-rater agreement.
Read the evidence conservatively
The four estimands stack into a ladder of claim strength. The discipline is to report the weakest rung the evidence actually supports — and most public claims, including the headline GPT number, stop at rung one or two.
This is why “yielding is a hack” is the wrong conclusion — it's false. The defensible claim is sharper and more useful: INP optimization is incomplete until it distinguishes meaningful earlier feedback, reduced work, and displaced work — and as of 2026, the public web has enough instrumentation to tell them apart.
Built to be falsified
A study worth trusting can fail if it's wrong. The plan preregisters the checks that would sink it:
- Pre-trend test. Event-study leads (months −6 to −2) must be flat. If INP improves before detected adoption, the signal is proxying for broader optimization, not the yield change.
- Vendor-window test. GPT and CMP effects must concentrate around the documented release windows and among exposed origins only. If unexposed origins move identically, the vendor isn't the cause.
- Placebo metric. Yield adoption must not “improve” unrelated metrics like TTFB the same way. If it does, the model is confounded.
- Trace equivalence. The no-yield counterfactual must reach the same final state — same ad auction, same consent, same DOM. If disabling yield changes the outcome, the comparison is void and excluded.
- Carryover test. Every lab scenario runs a second interaction. Yield-only isn't beneficial if it simply shoves the cost into the user's next tap.
- Detector falsification. The detector must reject analytics timers, polling, retries and animation tickers. A timer counts as yield only when the AST places it inside an interaction path.
What to do before the full run lands
The decomposition is a research program, but the discipline is usable today. You don't need the global share to stop fooling yourself on your own site.
- Site owners: never treat yielding as a substitute for deleting work. Pair INP with an interaction completion time, Long Animation Frame attribution, post-input blocking, and next-interaction delay. Ask of every INP win: did the task finish faster, did the user see meaningful feedback sooner, or did the work just move later?
- Third-party vendors: when you ship yielding, publish the work and completion effect alongside the INP effect. GPT and Prebid already expose the scheduling mechanism in public docs — the missing piece is a CPU-time and task-completion benchmark for a representative interaction.
- Metric designers: keep INP — visible responsiveness matters — but give it companions for high-stakes optimization: Interaction Completion Time, Interaction Total Work, and Carryover Input Delay. Not to replace INP, but to stop it from being asked to measure more than it was built to.
Limitations
CrUX is a population, not a census
It reports eligible Chrome users over traffic thresholds — not other browsers, not low-traffic origins. Conclusions generalize to the CrUX-eligible public web, the stated target.
The vendor numbers aren't independently reproducible
The 55.58% → 66.12% GPT figure is a Chrome release-note statistic, not something an outside analyst can yet rebuild from public CrUX. We cite it as documented evidence of direction and scale, not as a verified coefficient.
TBT divergence motivates, it doesn't prove
The +58% mobile TBT trend is why the work-vs-scheduling question matters; it is not itself evidence of gaming. Proof needs matched adoption, controlled replay and completion measurement.
No fabricated share
This release is the design plus verified facts. It does not report a fitted global yield-only share. The kit is built to produce one — and to be audited when it does.
Data, code & sources
Published under CC BY 4.0: the registered analysis plan, the source-coded evidence register, the yield-pattern detector codebook, the HTTP Archive + CrUX SQL, the field RUM snippet, the Playwright lab-replay harness and the micro-UX spec — everything needed to run the audit and to check it.
Browse the artefacts
Key sources
- Chrome UX Report team. CrUX release notes — CMP yielding (Mar 2024) and the GPT mobile INP pass-rate move 55.58% → 66.12% (Aug 2024); May 2026 baseline of 18.4M origins, 86.6% good INP.
- Pollard, B. et al. (2026). Performance, 2025 Web Almanac — mobile good-INP 74%→77%, top-1k 53%→63%, median mobile TBT +58% (1,209→1,916 ms).
- Google Search Central (2023). Introducing INP to Core Web Vitals & web.dev. Interaction to Next Paint — the FID→INP shift and the input-delay / processing / presentation decomposition.
- Wagner, J. (2024). Use scheduler.yield() to break up long tasks; W3C. Long Animation Frames API — the scheduling primitive and the lab/RUM attribution surface.
- Google Publisher Tag.
threadYieldreference; Prebid.setConfig(command-queue yield) — the documented third-party yield mechanisms. - Pollard, B. & Web Vitals Feedback (2024). Improving INP with setTimeout; Ruter, D. (2024). Goodhart's Law in action — the qualitative critique this audit makes measurable.
Cite this study
PageSpeedAudit Research (2026). Earlier paint, or less work? The INP
yield-gaming audit: separating earlier paint from less work in web
responsiveness, 2024-2026.
https://pagespeedaudit.com/research/earlier-paint-or-less-work
@misc{pagespeedaudit2026inpyield,
title = {Earlier paint, or less work? The INP yield-gaming audit},
author = {{PageSpeedAudit Research}},
year = {2026},
url = {https://pagespeedaudit.com/research/earlier-paint-or-less-work},
note = {Registered design + replication kit, CC BY 4.0}
}Is your INP win real, or just earlier paint?
A PageSpeedAudit report reads your lab run and your CrUX field data together, attributes INP to the interactions that actually cost users, and separates a real work reduction from a repaint that only moved the metric. See the sister studies “When does lab predict field?” and “How many Lighthouse runs prove a change?”