inp-analyser is an open-source CLI that diagnoses Interaction to Next Paint, reconciled against real-user field data. An open-source tool by FullStack Optimization / Franz Enzenhofer.
17Trace detectors
95%Confidence intervals
MITLicence
Anatomy of one interaction
Example interaction, illustrative lengths, not a measurement: from the tap to the next paint in three phases, on a 0 to 300 ms scale with Google's 200 ms "good" threshold.
01Input delaymain thread busy
02Processingevent handlers run
03Presentationstyle, layout, paint
Key facts
Field INP checked against PSI
95% confidence intervals
Causal third-party tests
Diagnoses, never prescribes
01 / The metric
What INP is.Three phases per tap.
Interaction to Next Paint is the Core Web Vital for responsiveness. For every page visit, the browser measures how long each click, tap and key press takes until the next frame is painted; the page's INP is (close to) the slowest of them. Google reports the 75th percentile over 28 days of real Chrome users.
INP p75 thresholds from web.dev: good up to 200 ms, needs improvement up to 500 ms, poor above.
Every interaction has three phases, and each has different causes (Optimize INP):
01Input delay
The main thread is busy (often a long task) when the user taps.
phase: input-delay
02Processing duration
The event handlers themselves run.
phase: processing
03Presentation delay
Style, layout, paint and any script that squeezes in before the next frame.
phase: presentation
Lighthouse and PSI give you a number. This tool gives you the reasons.
02 / What it finds
Six facts.Every single issue.
Every issue in the report carries the same set of facts. The examples are real output (bundled test site, a third-party script adding 200 ms per click; and Wikipedia):
01 / Elementbutton#apply-sort; on Wikipedia div#mwBA > a:nth-of-type(2)Discovered interaction target (CSS selector)
03 / ScriptknownDeltaListener (http://cdn.thirdparty.test:63958/known-delta.js:4:65), 198 msJS samples in a Chrome trace: URL, line, function
04 / OwnerTest Tracker Inc. (3rd party); blocking it: 134 ms faster (95% CI 97-179 ms)third-party-web entity map, extendable
05 / Millisecondsmedian 222 ms (95% CI 221-223 ms)Exact order-statistic CI of the median
06 / Certaintyconfirmed, fired in 8 of 8 runsScreening vs deep-dive runs, Wilson interval
The headline is always the field number: the CrUX p75 that PageSpeed Insights and Search Console show. Lab values are evidence, labelled lab @ CPU Nx. It diagnoses; it never prints fixes.
03 / Examples: real runs
Real pages.Real findings.
Unedited runs of inp analyse on real pages: field data first, then what the lab found, with element, phase, script, owner, milliseconds and certainty. Every number below comes from the run files in examples/.
Rendering work dominates a slow interaction (presentation delay is the largest phase)
Element
button#searchIcon
Evidence
style: 2 ms
Evidence
layout: 1 ms
Time
median 201 ms
Certainty
screening only
Runs
fired in 1 of 1 runs (95% CI 21-100%)
Showing 3 of 8 issues, confirmed first.
terminal.txt
Issues (8, ranked):
1. [needs improvement | confirmed | input delay] Same element is slower when tapped while the page boots
div#mwBA > a:nth-of-type(2) - lab @ CPU 4x, mobile: effect 199 ms (Hodges-Lehmann shift) (95% CI 116-265 ms); fired in 9 of 9 runs (95% CI 70-100%)
evidence: boot median: 277 ms
why this counts: https://web.dev/articles/optimize-input-delay
2. [needs improvement | screening only | context] Most of a slow interaction is not main-thread work (compositor / GPU / frame wait)
button#searchIcon - lab @ CPU 4x, mobile: median 258 ms; fired in 1 of 1 runs (95% CI 21-100%)
evidence: not explained by main-thread work: 258 ms of 308 ms
why this counts: https://web.dev/articles/inp#whats_in_an_interaction
3. [needs improvement | screening only | presentation delay] Rendering work dominates a slow interaction (presentation delay is the largest phase)
button#searchIcon - lab @ CPU 4x, mobile: median 201 ms; fired in 1 of 1 runs (95% CI 21-100%)
evidence: style: 2 ms
why this counts: https://web.dev/articles/inp#good-score
4. [needs improvement | screening only | context] Large DOM (more than ~800 / ~1,400 elements, Lighthouse dom-size)
...
Run: 147 runs (0 excluded), 151 page loads, seed 42, Chrome/155.0.8059.39, lab @ CPU 4x, mobile; INCOMPLETE: time budget reached before deep-dive block 102
DIV class='onetrust-pc-dark-filter ot-fade-in' visibility: failure code 8200; properties: visibility
Certainty
screening only
Runs
fired in 1 of 1 runs (95% CI 21-100%)
terminal.txt
Issues (3, ranked):
1. [info | screening only | context] Large DOM (more than ~800 / ~1,400 elements, Lighthouse dom-size)
lab @ CPU 4x, mobile: no duration attached; fired in 5 of 5 runs (95% CI 57-100%)
evidence: DOM elements: 2178
why this counts: https://developer.chrome.com/docs/lighthouse/performance/dom-size
2. [info | screening only | context] Uncaught exceptions on the page during the run
lab @ CPU 4x, mobile: no duration attached; fired in 5 of 5 runs (95% CI 57-100%)
evidence: exception: Script error.
why this counts: https://developer.mozilla.org/en-US/docs/Web/API/Window/error_event
3. [info | screening only | presentation delay] Non-composited animation runs during the interaction (needs layout/paint every frame)
lab @ CPU 4x, mobile: no duration attached; fired in 1 of 1 runs (95% CI 21-100%)
evidence: DIV id='onetrust-banner-sdk' class='otFlat ot-iab-2 bottom vertical-align-content ot-buttons-f...
why this counts: https://developer.chrome.com/docs/lighthouse/performance/non-composited-animations
Run: 18 runs (0 excluded), 22 page loads, seed 42, Chrome/155.0.8059.39, lab @ CPU 4x, mobile
Lab: pending. The lab runs on 11 Nov 2026 did not finish: one page load timed out after 60 s, and the latest run met a Cloudflare challenge page. The tool stops at a challenge ([safety] bot wall) instead of measuring it or retrying, because a challenge page is not the page. So this card shows the real field data only, and no lab numbers.
inp field
phone : INP p75 229 ms (url level, 2026-10-13..2026-11-09) good 69.8% / needs improvement 22.7% / poor 7.5% | PSI: equal
desktop: INP p75 60 ms (url level, 2026-10-13..2026-11-09) good 94.0% / needs improvement 3.4% / poor 2.7% | PSI: equal
- CrUX API: p75 and good/NI/poor shares of real Chrome users over the 28-day collection period 2026-10-13..2026-11-09. https://developer.chrome.com/docs/crux/api
- CrUX History API: 25 weekly 28-day periods, oldest first; ineligible periods are null. https://developer.chrome.com/docs/crux/history-api
- PageSpeed Insights loadingExperience/originLoadingExperience (analysed 2026-11-11T11:20:53.717Z / 2026-11-11T11:20:53.665Z): separate source next to CrUX, reports no collection period. https://developers.google.com/speed/docs/insights/rest/v5/pagespeedapi/runpagespeed
- CrUX history PHONE url https://techcrunch.com/2026/11/07/amazons-new-basic-kindle-proves-you-dont-need-all-the-bells-and-whistles/: 24 of 25 periods ineligible (kept as null).
- CrUX history DESKTOP url https://techcrunch.com/2026/11/07/amazons-new-basic-kindle-proves-you-dont-need-all-the-bells-and-whistles/: 24 of 25 periods ineligible (kept as null).
- CrUX PHONE vs PSI mobile, url level: identical (p75 229 ms, same good/NI/poor shares).
- CrUX PHONE vs PSI mobile, origin level: identical (p75 177 ms, same good/NI/poor shares).
- CrUX DESKTOP vs PSI desktop, url level: identical (p75 60 ms, same good/NI/poor shares).
- CrUX DESKTOP vs PSI desktop, origin level: identical (p75 68 ms, same good/NI/poor shares).
[inp] field: examples/techcrunch-basic-kindle/field.json
The tool also says what it does not know: on Wikipedia the search button's slow tap is mostly compositor / GPU time, so no script is blamed, and one-run findings stay screening only.
Ground truth: the bundled test site
The repository ships a test site where a third-party script adds exactly 200 ms to every click. The tool has to find it, name it and prove it (run of 11 Nov 2026, mobile, CPU 4x, seed 42, full output).
processing/slow-event-handlersprocessingconfirmed
Bundled test site, page ab-known-delta: a third-party script adds 200 ms to every click. The tool names it.
Element
button#apply-sort
Script
knownDeltaListener (http://cdn.thirdparty.test:63958/known-delta.js:4:65) via #document.onclick, 198 ms
Owner
Test Tracker Inc. (3rd party)
Time
lab @ CPU 4x, mobile: median 222 ms, 95% CI [221, 223]
Certainty
confirmed
Runs
fired in 8 of 8 runs (95% CI 68-100%)
third-party/causal-deltacontextconfirmed
Same page, proven by blocking: the tap gets faster without Test Tracker Inc. - cause, not just correlation.
Element
button#apply-sort
Owner
Test Tracker Inc. (3rd party), blocked vs allowed
Time
134 ms faster when blocked (Hodges-Lehmann shift, 95% CI 97-179 ms); with third parties 231 ms
Field data for en.wikipedia.org/wiki/Main_Page, fetched with inp field on 11 Nov 2026, including 25 weeks of CrUX history.
130ms
good (200 ms or less)
URL level - CrUX, 28 days 2026-10-12 to 2026-11-08 - real Chrome users on phones
good 86.5%
needs improvement 9.7%
poor 3.9%
PSI parity: PageSpeed Insights shows the identical value - p75 130 ms and the same good / needs improvement / poor shares, at URL and origin level.
Desktop, URL level61 ms
good 96.8%
needs improvement 2.3%
poor 0.9%
Whole origin en.wikipedia.org87 ms phone / 49 ms desktop
Phone INP p75, 25 weekly CrUX periods
Green line with dots = INP p75 on phones, /wiki/Main_Page, URL level, one point per 28-day period (n = 25, weekly steps)
Grey lines = 5 ms gridlines. The y axis starts at 120 ms, not 0, so the small change stays visible.
Source: CrUX History API, phone, URL level, metric interaction_to_next_paint p75, fetched 11 Nov 2026 with inp field. Each point covers 28 days; consecutive points overlap by 21 days.
The same field data in the terminal
inp field
$ inp field https://en.wikipedia.org/wiki/Main_Page
phone : INP p75 130 ms (url level, 2026-10-12..2026-11-08) good 86.5% / needs improvement 9.7% / poor 3.9% | PSI: equal
desktop: INP p75 61 ms (url level, 2026-10-12..2026-11-08) good 96.8% / needs improvement 2.3% / poor 0.9% | PSI: equal - CrUX PHONE vs PSI mobile, url level: identical (p75 130 ms, same good/NI/poor shares).
- CrUX PHONE vs PSI mobile, origin level: identical (p75 87 ms, same good/NI/poor shares).
- CrUX DESKTOP vs PSI desktop, url level: identical (p75 61 ms, same good/NI/poor shares).
- CrUX DESKTOP vs PSI desktop, origin level: identical (p75 49 ms, same good/NI/poor shares).
[inp] field: inp-report-en.wikipedia.org-202611110531/field.json
Excerpt of the output fetched on 11 Nov 2026; the full output, with the source notes per API, is in the README.
04 / How it works
Seven stages.One verdict.
One pinned, headless Chrome. One page load at a time, in seeded random order. Every stage feeds the next, and the end result is checked against the real-user number.
Field data. CrUX and PSI per device, URL and origin level, plus 25 weeks of history, fetched before any page load.
Discovery + safety guard. Two passes keep only stable targets. Money, deletion, logout and form-submit actions are never clicked; mutating requests and navigations are blocked.
Screening. Every target is tapped once the page is idle, and while it is still booting, in 3 interleaved blocks.
Deep-dive attribution. Every scenario slower than 200 ms gets timing blocks until the median CI is narrow, then 5 traced attribution runs.
Third-party causal blocks. Paired runs with third parties allowed and blocked prove which owner costs how many milliseconds, or flag the result as confounded.
Rules + statistics. 17 trace-based detectors, exact median CIs, Wilson intervals, Hodges-Lehmann shifts, Mann-Whitney with Holm correction.
Report. Issues, comparisons and limitations, with a verdict on whether the lab reaches the field p75.
Every block is health-gated: if the machine drifts, the block is kept in the raw data but excluded from all statistics. The tool refuses to run on battery, in Low Power Mode or under thermal throttling.
05 / Quick start
Clone it.Run it on any URL.
Requirements: Node.js 26 or newer, git, and about 500 MB of disk for the pinned Chrome for Testing build. Runs on macOS and Linux.
git clone https://github.com/franzenzenhofer/inp-analyser
cd inp-analyser
npm ci
npm run chrome:install
export INP_GOOGLE_API_KEY=... # optional: field data from CrUX + PSI
npx tsx src/cli.ts analyse https://en.wikipedia.org/wiki/Main_Page --quick
The key needs the Chrome UX Report API and the PageSpeed Insights API enabled. No key yet? Add --no-field for a lab-only run. --quick stops after screening (typically 20 to 40 minutes); drop it for the full analysis. Then open report.html in the run directory.
Commands
inp field <url>
CrUX + PSI field INP for phone and desktop. No page loads. Writes field.json.
inp discover <url>
Lists the interaction targets analyse would measure (two passes, stable targets only), their safety class, excluded targets with the reason, and global third-party listeners.
inp analyse <url>
The full pipeline: preflight, discovery, screening, deep-dive, third-party causal tests, diagnosis, report.
inp report <dir>
Rebuilds report.json and report.html from a run directory (runs.jsonl + meta.json).
inp trace <file>
Issues in an existing DevTools Performance recording (.json or .json.gz). One recording is one sample: no statistics.
inp compare <before> <after>
Before/after on two run directories: Hodges-Lehmann shift + 95% CI, Mann-Whitney p (Holm-corrected), Cliff's delta per shared scenario.
inp calibrate
Measures Lighthouse BenchmarkIndex under each CPU throttling rate on this machine and names the device class each rate reaches.
All commands, options and the full methodology: README on GitHub.
06 / Agent skill
Ask your agent.It knows the rules.
The repository ships an agent skill for Claude Code and other agents that read the skill format. It teaches the agent when to use the tool, how to read report.json, and to never present a lab number as the INP.
cp -R skills/inp-analyser ~/.claude/skills/
Then just ask:
"Why is INP poor on https://example.com/?"
"What INP does PSI show for https://en.wikipedia.org/wiki/Main_Page, phone and desktop?"
"Analyse this DevTools trace for slow interactions."
