Interaction to Next Paint replaced First Input Delay as the interaction metric because FID measured only the gate, the delay before a handler could run. INP measures the whole journey, from input to the next paint that shows the response.
The 98th percentile choice is deliberate. It filters the outliers a single flaky script can cause, while still capturing the experience of the vast majority of users. One slow interaction can spike the score from 80 to 400 milliseconds.
INP is the vital that desktop teams underestimate, because desktop hardware masks main thread cost. This dive covers the measurement, the offenders, and the rebuild.
How INP Is Measured
Every interaction, a click, a keypress, a pointer move counted as interactive, goes through a sequence: the event runs, the browser processes it, and the next paint shows the result. INP measures the delay from input to that paint.
Continuous interactions like scrolling and drags are excluded, the metric focuses on discrete interactions that must feel instant. Typing triggers per-keystroke events, each an interaction, so a heavy input handler multiplies the cost.
The field value is the 98th percentile over the session. A single slow interaction defines the score even when the median is flawless, because the 98th captures the worst type-cased experience.
Finding the Slow Interactions
Instrument before you guess. Interaction timing entries in the field tell you which element, type and duration cost the score. Debug in the lab by reproducing the flagged interaction on a throttled device.
The common offenders are predictable. Search boxes that filter on every keystroke, accordions that re-render the whole tree, menus that trigger layout on open, and grids that bind heavy listeners to every cell.
Throttling matters for discovery. A handler that passes on the developer machine fails on a midrange phone, so reproduce the flagged interaction under CPU throttling before fixing.
| Offender | Cost | Fix Direction |
|---|---|---|
| Filter on every keystroke | Rebuild per key | Debounce or index |
| Open menu re-renders tree | Layout cascade | Cache or isolate |
| Heavy click handler | Blocking task | Defer and chunk |
| Layout thrash loop | Forced reflow | Batch reads and writes |
The Main Thread Budget
The main thread is the bottleneck. Parsing, executing, styling and painting all share it, and a heavy background task sits directly in front of the user's interaction.
Set a budget per interaction. The handler plus the work it triggers must complete inside the vital window, which usually means chunking large work and yielding between chunks.
Prioritize by when the work is needed. Defer analytics, prefetch, and warm-up work until the interaction finishes, so the handler never competes with the housekeeping.
INP Failures
Trusting the lab median is the first failure. A median of 60 milliseconds hides the 98th at 450, and the field reads the 98th.
Chasing framework myths is second. Swapping the framework because performance is poor ignores that the whole tree re-renders on every interaction, a behavior the framework did not mandate.
Ignoring the hydration surface is third. Client-rendered pages cost the main thread at load and again at interaction, so the heaviest handlers live on the pages that hydrate the most.
- Medians reported as wins while p98 fails
- Framework blame when the render pattern is the cause
- No instrumented interaction data in the field
- Long blocker tasks ahead of handlers
Rebuild Around the Budget
Instrument the three largest interactions per template, reproduce each under throttle, and fix by order of field cost. One hundred milliseconds off the worst handler moves the vital more than fifty off the median.
Refactor handlers to answer first and compute later. Render the user-visible result immediately, then do the expensive enrichment, charting or fetching after the interaction paints.
Chunk any work that cannot be deferred. A long sort, filter or recalculation gets split into parts with yields between, so it no longer appears to the vital as one blocker.
Real-World Considerations
Third-party scripts consume the same main thread the vital measures. A consent manager or chat widget doing work during a user's interaction inflates INP even with a perfect first-party handler.
Personalization and tags multiply the load. Every tag is another script competing for the thread, so the third-party audit and the INP fix ship together.
Native apps set the expectation. Users compare the page to the app they use elsewhere, so the interaction standard in 2026 is closer to native than to the slow web of a decade ago.
Where to Spend
Interactive surfaces pay first: search, forms, filters, accordions, any place users constantly touch. One good fix there moves the field score more than a hundred cosmetic tweaks.
Read-heavy pages need the lighter pass, no heavy handlers to tune, just the discipline of not adding interactive weight where the content never needed it.
Implementation Checklist
- Instrument interaction timing in the field
- Find the three slowest interactions per template
- Reproduce each under CPU throttling
- Set a per-interaction main thread budget
- Render visible results before expensive work
- Chunk anything that cannot be deferred
Final Thoughts
INP is the interaction score, and it is won on the main thread. The vital cannot be faked in the lab because its worst interaction still surfaces at the 98th percentile.
Instrument, reproduce, and rebuild the handlers around a budget. The score in the field follows the discipline.
Frequently Asked Questions
Because the worst real interaction is what users remember. A median hides the slow menu that annoyed every third visitor, the 98th keeps it honest.
Yes, when rendering is isolated and handlers are bounded. The framework is not the problem, uncontrolled re-renders and blocker tasks are.
Interaction timing entries in the field report element, type and duration. Flag the worst, reproduce on throttle, and fix by field cost.
