Interaction to Next Paint (INP)

Interaction to Next Paint, or INP, is the responsiveness metric in Core Web Vitals. It measures the delay between a user interacting with your page and the page visually updating in response. You tap a menu, and INP times how long until something actually changes on screen. A high INP is that horrible feeling where you tap a button and nothing happens, so you tap it again, and then both taps register at once and you end up somewhere you never meant to go. Of the three Core Web Vitals, INP is the one that exposes lazy front-end engineering most ruthlessly. A page can load fast and stay perfectly stable and still feel broken the moment you try to use it, because all the heavy lifting got deferred to the moment of interaction. INP catches exactly that. It is the metric that separates pages that look fast from pages that actually are.

Why INP replaced First Input Delay

INP took over from First Input Delay, and the upgrade matters. First Input Delay only measured the very first interaction on the page, and only the input delay portion, not the full response. INP watches interactions throughout the entire visit and measures the whole round trip from tap to next paint. It is a much harder, much more honest test. First Input Delay was easy to pass and easy to game, because most pages are idle at the exact moment of the first click. INP is neither, which is exactly why it is a better signal. It judges your page the way a real person uses it: over and over, deep into the session, when your scripts are busy.

INP problems almost always trace back to JavaScript hogging the main thread. The browser has one main thread for both running your scripts and responding to the user, so any time a script monopolizes it, the user is left waiting for their turn. When the browser is busy running a long task, it cannot react to a tap until that work finishes. The fix is rarely about loading less and almost always about doing less work at the wrong moment. The usual suspects are long JavaScript tasks, heavy event handlers that do too much synchronously, expensive DOM updates triggered by one interaction, and third-party scripts running their own work in response to user events.

• Long JavaScript tasks that block the main thread when the user interacts.
• Heavy event handlers that do too much work synchronously on click or input.
• Large, expensive DOM updates triggered by a single interaction.
• Third-party scripts running their own work in response to user events.

1. 1Use the field data in PageSpeed Insights or Search Console to confirm INP is actually a problem for real users.
2. 2Reproduce the slow interaction in Chrome DevTools and record the performance trace to find the long task.
3. 3Break up the long task, defer non-urgent work, and trim heavy event handlers, then re-measure.