What Is INP (Interaction to Next Paint)?
INP explained: how interaction responsiveness is measured, the 200 ms threshold, and why JavaScript weight is the usual suspect.
Interaction to Next Paint (INP) measures how long the page takes to visually respond after a click, tap, or keypress — the lag between 'I pressed the button' and 'something visibly happened'. It replaced FID as a Core Web Vital in 2024 because FID measured only the first interaction's delay; INP grades the whole session and reports (approximately) the worst case. Good: under 200 ms. Poor: above 500 ms, at p75.
What makes INP bad
One thing, with many costumes: a busy main thread. The browser cannot paint a response while JavaScript runs, so every long task is potential interaction lag —
- Heavy event handlers doing synchronous work on click.
- Framework re-renders cascading through big component trees.
- Hydration in SSR apps — famously, taps that do nothing because the page looks ready before it is.
- Third-party scripts — tag managers, chat widgets, analytics suites — running their bookkeeping on your user's click path.
Why INP is the SPA truth-teller
Single-page apps front-load their cost: after one slow initial load, navigation is 'instant' — except every interaction now runs through JavaScript. SPAs routinely ace LCP and flunk INP, which is why SPA measurement treats it as the primary health metric. It also barely exists in lab tools — Lighthouse cannot click around your app like a frustrated user; only field data shows real INP.
Improving it
- Break long tasks: yield to the main thread (scheduler.yield, setTimeout chunking) so paints can interleave.
- Respond first, compute second: paint the pressed state immediately, do the work after.
- Audit third-party weight — the fastest INP fix is deleting a script. A 1.1 KB tracker exists precisely so measurement is never the bottleneck.
- Watch field INP per page (monitoring routine) — regressions ship with features, and the deploy correlation is the diagnosis.