Interaction to Next Paint (INP)

Why it replaced First Input Delay

INP became a Core Web Vital in March 2024, replacing First Input Delay (FID). FID only measured the delay before the browser began handling the first interaction on a page. INP looks at every click, tap and key press during the visit, measures the full time until the next frame is painted, and reports one of the slowest, ignoring rare outliers on pages with many interactions (web.dev).

The thresholds are 200 milliseconds or less for good and over 500 milliseconds for poor, at the 75th percentile of visits.

What makes INP slow

Almost always, the cause is JavaScript keeping the main thread busy:

• Long tasks already running when the user taps, such as hydration of a large app or a third-party script.
• Heavy event handlers that do a lot of work before updating the screen.
• Large re-renders that touch a big part of the DOM for a small change.
• Third-party scripts such as chat widgets, tag managers and A/B testing tools.

How to improve it

1. Find the slow interaction. Field data tells you INP is poor; it does not tell you which interaction. Real-user monitoring with attribution, or manual testing with the browser’s performance panel, narrows it down.
2. Show feedback first. Update the UI immediately, then do the expensive work.
3. Break up long tasks by yielding back to the main thread between chunks of work.
4. Defer or remove third-party scripts that are not needed for the first interaction.
5. Reduce DOM size on very large pages.

INP can only be measured in the field. In lab tools, Total Blocking Time is the closest stand-in. The Core Web Vitals checker shows field INP where Chrome has enough data.