Interaction to Next Paint (INP)
Slap yourself if
You think INP is just FID with a new name or only about click handlers.
Why this exists
INP exists because users interact with pages many times, not once. Measuring only the first delay hid ongoing responsiveness problems caused by long tasks, rendering work, and poorly chunked updates throughout a session.
Mental model
INP measures the full interaction lifecycle. It starts when the user acts and ends when the UI visibly responds. If anything blocks that path — JavaScript, layout, paint — it counts.
- A user interaction occurs (pointer, keyboard, tap).
- The event waits if the main thread is busy.
- Event handlers execute and schedule work.
- Rendering and paint occur to reflect the result.
- INP records the worst interaction delay observed.
- Optimizing only the first interaction.
- Reducing handler time but ignoring rendering cost.
- Assuming async handlers prevent INP issues.
- Measuring in synthetic tests without real interaction patterns.
INP measures the latency of user interactions across a page’s lifetime, from input to the next paint, capturing both main-thread blocking and render work that delays visible feedback.
- Long tasks after initial load
- Heavy re-renders on user input
- State updates that trigger layout thrash
- INP discussed without mentioning paint
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.