Interaction to Next Paint measures the latency from a user interaction until the next visual update, indicating how responsive a page feels in use.
Trace a real interaction
INP considers interactions during a page visit and reports the interaction that best represents its worst responsiveness. The delay can come from input handling, long JavaScript tasks, synchronous layout work or a paint delayed by other work. A click that eventually succeeds may still feel unresponsive.
How to inspect it
Use field data to locate affected page groups, then record a trace while repeating a realistic tap, click or key action. Break the interaction into input delay, processing time and presentation delay. Test the route on a constrained device profile; a desktop trace can conceal main-thread pressure.
How to implement or improve it
Remove unnecessary synchronous work from the handler, split long tasks, avoid layout thrashing and show the next meaningful state promptly. Verify the interaction still completes, remains keyboard accessible and does not shift the page. Compare like-for-like traces before and after the change.
Limits and common mistakes
Do not optimise only the first click or replace interaction work with a superficial spinner. The page must actually acknowledge and complete the user’s task.
Triage an INP finding by splitting the interaction into input delay, processing time and presentation delay. Record the exact click, tap or keyboard action, the element involved and the device profile. A long task before the handler suggests main-thread contention; a slow handler may be doing synchronous computation; a delayed paint can indicate style or layout work after the handler. For example, a filter click that synchronously rebuilds a large list can be improved by reducing the update scope and yielding non-essential work, but the result must still announce progress and remain keyboard operable. Reproduce the same interaction after the change and inspect both the trace and the visible response.