Interaction to Next Paint (INP)

How INP works

Every interaction has three parts: input delay (waiting for the main thread to be free), processing time (running your event handlers), and presentation delay (style, layout and paint of the next frame).

INP reports roughly the worst interaction during the visit — the slowest one, ignoring one outlier for every 50 interactions on very interactive pages.

Because it needs real interactions, INP can only be measured in the field or by interacting yourself. Lab tools use Total Blocking Time as a proxy.

Common causes of a poor INP

Long tasks on the main thread

A 300 ms JavaScript task that happens to be running when the user taps delays the response by up to 300 ms.

Heavy event handlers

Doing all the work synchronously in the click handler before the browser can paint any feedback.

Large DOM and expensive rendering

Thousands of nodes make every style and layout recalculation slow.

Third-party scripts

Tag managers, chat widgets and ad scripts compete for the same main thread.

How to improve INP

1. Show feedback first, then do the work: update the UI, then yield (await scheduler.yield() or setTimeout) before the heavy part.
2. Break long tasks into chunks under 50 ms.
3. Debounce input handlers and avoid layout thrashing (reading layout after writing styles).
4. Move heavy computation to a Web Worker.
5. Audit and defer third-party scripts; keep the DOM small.

A heavy JavaScript payload is the usual root cause; the page size checker shows how much script your page ships.

Enter your field numbers in the Core Web Vitals checker to see whether you pass.