INP Calculator
Time the interaction — input delay, processing and paint delay against the 200-millisecond line and the 60-fps frame budget it implies.
INP Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- Three-phase model of one interaction, not a census
- Reads trace values; it does not record them
In short: 40 + 90 + 50 = 180 ms of INP — good, one frame's breath from the 200 ms line, and 10.8 frames at 60 fps spent on a single interaction. INP is the whole conversation, not the acknowledgement: input delay (the page was busy and heard you late), processing (your handlers ran), then presentation delay (the paint that proves it happened). FID only ever priced the first phase — which is why pages that passed FID still felt dead.
Formula
INP = input delay + processing + presentation delay
An interaction is a relay of three phases: the page notices (input delay), the handlers run (processing), and the next paint shows it (presentation delay). Good is 200 ms or better at the 75th percentile of ALL interactions across the page's life; poor is past 500 ms. The frame math makes the line physical: 60 fps gives 16.67 ms per frame, so a 200 ms interaction spends about 12 frames — and the user can feel every one of them.
Worked Example
- Enter the three phase durations from a trace.
- Read the total, the band and the frame cost.
- Cut the biggest phase — handlers are usually guilty.
Defaults: 180 ms, good, 10.8 frames. Drive processing to 250 and the total reads 340 ms — needs improvement, with the handler phase named at 73.5%.
Strengths & Limits Of This Model
Where this engine is strong
- Frame budget converts ms to something felt
- Biggest phase named with its own fix
Where it stops
- No percentile simulation — p75 field data is the input
Practical Use Cases
Handler audits
price the long task that ate a tap
Third-party trials
what the chat widget costs a click
Perf budgets
a ms ceiling per interaction in CI
Methodology & Editorial Standards
Computation runs in IEEE-754 double precision at full internal precision; rounding to two decimal places occurs strictly at the display layer, so no cumulative drift enters the result. All monetary outputs use accounting presentation — grouped thousands, two decimals, negatives in parentheses — so figures can be transcribed directly into a model or working paper. Division-by-zero and out-of-domain inputs return an em-dash rather than a misleading number.
This engine was reconciled against an independent reference implementation and hand-verified for the worked example above before release. Our full five-stage review process is published on the About Us page.
Disclaimer. This calculator is provided for informational and modelling purposes only and does not constitute financial, tax, legal, medical, or engineering advice. Verify all figures with a qualified professional before acting on them.
INP Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
What is INP, in one sentence?
Interaction to Next Paint: for each click, tap or keypress, the time from the event to the next visual confirmation, reported at the 75th percentile of all interactions over the page's life. It replaced First Input Delay as a Core Web Vital in March 2024.
Why did FID have to die?
FID measured only input delay — when your handler STARTED. A page could acknowledge the tap instantly and then freeze for four seconds, passing FID while feeling broken. INP waits for the paint that proves the interaction finished, which is what users were judging all along.
What are the three phases?
Input delay: the main thread was busy and the event waited. Processing: your handlers and their synchronous work. Presentation delay: from handlers done to the next paint — long style recalc or a busy frame lives here. All three count; optimizing only the handler misses the other two waiting rooms.
What is a good INP?
200 ms or better at p75; 200 to 500 ms is needs improvement; past 500 ms is poor. The thresholds track perception research — about 100 to 200 ms is where a response stops feeling connected to the action that caused it.
What eats input delay when the page looks idle?
Everything scheduled before the tap: long framework hydration tasks, third-party tags, analytics. The handler was ready; the main thread was not. Breaking long tasks into under-50-ms chunks and deferring non-critical scripts is the fix.
How many frames is 200 ms?
About 12 at 60 fps (16.67 ms per frame). A failing 500 ms interaction costs 30 frames — half a second of unresponsive UI. The frame budget turns an abstract threshold into a number a developer can feel: every handler you add to a click spends the same frames the user is watching.
Which interactions count?
All of them across the page's whole life — clicks, taps and keypresses, including those inside menus and dialogs. The 75th percentile means the worst quarter of your interactions sets the grade, so one catastrophic handler on a rarely-clicked button can still fail the page.
How do I fix a poor INP?
Profile the interaction: if processing dominates, split the long task, debounce ruthless work, move it off the main thread. If input delay dominates, evict the third-party tags hogging the thread. If presentation dominates, shrink the DOM you are repainting and simplify the styles the change triggers.