Performance
Interaction to Next Paint
Also called INP.
Interaction to Next Paint is the latency from a click, tap, or key press until the browser paints the next frame, taken across the page's life. It replaced First Input Delay as a Core Web Vital in March 2024.
How it is measured
Each interaction has input delay, processing time, and presentation delay. The page's INP is roughly the worst interaction, with an outlier allowance of one per 50 on busy pages. Good is 200 ms or less at p75.
It uses the Event Timing API. Lab tools approximate it with scripted interactions and Total Blocking Time, so field data is the reliable source.
Worked example
A SaaS dashboard shows INP of 180 ms for the menu, 240 ms for the filter, and 610 ms for the export button, which runs a 480 ms synchronous loop. The reported INP is 610 ms and the page fails. Chunking the loop with `scheduler.yield()` brings that interaction to 170 ms.
The filter at 240 ms is next, because a re-render of 800 table rows takes 190 ms.
How it differs
Interaction to Next Paint covers all interactions and the paint. First Input Delay covered only the wait on the first. Long tasks are the usual cause of high INP. A page with good FID can still fail INP.
Common errors
Testing only the first click. Checking INP in Lighthouse and treating it as exact. Forgetting that INP includes the paint. Ignoring interactions with third-party widgets. Optimizing handlers while a heavy re-render remains.
In practice
Find the worst interaction in field data or the Web Vitals extension, record it in DevTools, and break the longest task into pieces. Reduce re-render size and defer non-urgent work.