Interaction to Next Paint(INP)

Long definition

INP replaced FID (First Input Delay) because FID only measured the first interaction, which ignored the fact that most frustration happens during later clicks — on menus, on filters, on "load more" buttons. INP captures all interactions and reports the slowest one (technically the p98 for pages with many interactions) as the page's INP.

An interaction's duration is the maximum of three phases:

1. Input delay — time from the user action until the event handler starts running. Usually dominated by the main thread being busy with JavaScript.
2. Processing time — the event handlers' actual work.
3. Presentation delay — time from the handlers returning until the browser paints the next frame.

The fix is almost always "stop blocking the main thread." Long tasks (> 50 ms) during active interactions kill INP. Typical culprits: third-party analytics scripts, large hydration costs in SPAs, unvirtualized long lists that reflow on filter toggle, synchronous parsing of big JSON payloads in a click handler.

Common misconceptions

• "INP is the same as response time to a click." It's end-to-end: click → handlers → next paint. Even if your handler is fast, if the paint is delayed by an unrelated long task, INP suffers.
• "SPA frameworks automatically have bad INP." Not automatically — but unoptimized hydration is the top INP killer on React/Vue sites. Islands, progressive hydration, or useDeferredValue patterns help.
• "I can fix INP by debouncing." Debouncing helps the handler frequency, not the duration of any one interaction. If your handler takes 800 ms, debouncing doesn't save you.
• "INP is only about JavaScript." Heavy CSS (large animations on interaction, filter effects) can also delay the next paint. Profile before assuming.