What is INP (Interaction to Next Paint)?

INP is the time from a user interaction until the page responds visually, and Google counts anything under 200 milliseconds as good.

It entered Core Web Vitals in March 2024, replacing FID. The change mattered: FID measured only the delay of the first interaction, while INP looks at every interaction in the session and measures not the delay but the full cycle — from input to the next paint.

The duration splits into three stages: input delay (the main thread is busy), processing time (event handlers), and presentation delay (until the browser paints the next frame). Most teams think only about the second; in field data the largest share usually goes to the first and the third.

The most effective treatments, in order: not loading unnecessary JavaScript at all, breaking up long tasks, and moving heavy computation to a background thread.

It cannot be measured reliably in lab tools, because the metric looks at real user interactions and an auditing tool does not interact with the page. For INP, field data is not an option but a necessity.

Every task running longer than fifty milliseconds leaves the page unresponsive for that time. Splitting the work into small pieces and handing control back to the browser in between does not change the total duration but keeps the page usable.

To set up measurement you can use the browser’s own reporting: a duration value arrives at the page for every interaction and can be sent to your own system. The advantage is detail — you can see which interaction is slow, on which page and on which element.

The single biggest determinant is usually a decision never taken as a performance decision: the front-end architecture. Pages that re-render on the client keep the main thread busy for the duration of that work, and every click made in that window is delayed.

• Do not load unnecessary JavaScript at all — the biggest gain is in the inventory.
• Break up long tasks — every task over fifty milliseconds freezes the page.
• Move heavy computation to the background — free the main thread.
• Weigh third-party scripts — chat bubble, analytics, advertising.
• Defer to after the interaction — everything not needed while the page loads.
• Measure from field data — it cannot be measured reliably in a lab.

The order is deliberate: a script that is never loaded costs nothing, and no optimisation can beat that result.

A practical target for staying under the threshold is that no task should exceed fifty milliseconds — because when an interaction lands in the middle of such a task, the delay grows by exactly that much.

If you want your own site measured and fixed at the source, our Core Web Vitals optimization starts from real-user data and delivers LCP, INP and CLS against a budget.