The Complete INP Guide for Modern Web Apps

Interaction to Next Paint replaced First Input Delay as a Core Web Vital because FID only measured the delay before the browser started processing an interaction — not whether the interaction actually felt fast. INP measures the full round trip: input, processing, and the next paint the user sees. It's a much harder, much more honest number.

In React apps, the usual suspects are large synchronous state updates, unmemoized re-renders cascading through a deep tree, and heavy work running on the interaction thread instead of being deferred. A button click that triggers a full list re-render, a context update, and a layout recalculation can easily blow past 200ms even on a fast device.

The fixes are unglamorous but effective: `useTransition` and `startTransition` for non-urgent state updates, code-splitting so the interaction handler isn't waiting on unrelated JavaScript to parse, and moving genuinely expensive work off the main thread with web workers where it's feasible. Virtualising long lists and debouncing search-as-you-type inputs routinely account for the biggest single wins we see.

Lab tools like Lighthouse are useful for catching regressions in CI, but INP is fundamentally a field metric real devices, real network conditions, real user patience. We wire up the `web-vitals` library to send INP (and its attribution data) to real-user-monitoring on every client project, because the interactions that hurt real users are rarely the ones you clicked during a demo.

On a recent admin dashboard rebuild, attribution data showed the worst offender wasn't the interaction handler at all it was a third-party analytics script blocking the main thread on every click. Removing it and lazy-loading it after first interaction cut INP from 340ms to 90ms with zero application code changes. Measure before you optimise; the answer is rarely where you assumed.