Making sense of interaction to next paint
INP replaced first input delay because responsiveness is about every tap, not just the first one.
From first input to every input
First input delay measured only the wait before the browser began handling a visitor's first interaction. It was a narrow view: a page could respond instantly to the first click and then freeze for half a second on every later one. Interaction to next paint looks at all interactions during a visit and reports one of the slowest, measuring the full time from input to the next frame the visitor sees.
A good score is under 200 milliseconds. Above 500 is poor.
The three parts of an interaction
- Input delay: the time before the event handler starts, usually because the main thread is busy with something else.
- Processing time: how long the event handlers themselves run.
- Presentation delay: the time to recalculate styles, lay out, and paint the result.
Each needs a different fix.
Reducing input delay
Input delay comes from long tasks already running when the visitor taps. Common sources are hydration of a large framework app, third-party scripts, and timers doing heavy work. Breaking long tasks into smaller pieces, deferring non-essential scripts, and reducing the amount of JavaScript that runs during load all help.
Reducing processing time
Event handlers often do more than they need to before the screen updates. A click handler that sends analytics, updates three stores, and recalculates a large list before showing feedback makes the visitor wait for all of it. Show the visual response first, then do the rest. Yielding to the browser between the two lets it paint the feedback immediately.
Reducing presentation delay
Large DOM trees and complex CSS make every style recalculation and layout slower. Interactions that change many elements at once, such as filtering a long list, are especially costly. Virtualizing long lists, using content-visibility for off-screen sections, and avoiding layout reads immediately after writes keep this phase short.
Finding the slow interactions
Lab tools only measure the interactions you script. Field data reveals the ones visitors actually perform. Collect INP with attribution, which records which element was interacted with and how long each phase took. Sorting by element usually points straight at two or three components responsible for most of the slow interactions.
A common surprise
Many teams discover that their worst interactions are not the complex ones but the simple ones that trigger unexpected work: opening a menu that re-renders the whole page, or typing in a search box that filters thousands of items on every keystroke. Small changes to these often move the whole site's score.