Under 200ms at the 75th percentile is good, 200 to 500 needs improvement, above 500 is poor. Note that a number in the needs-improvement band is often reported loosely as poor, which is not the same thing.

Why did my score get worse without any change?

If it coincided with the metric changing from the older responsiveness measure, nothing on your site got worse. INP measures more of the session and more of the path, so many sites saw a step change on the same code.

Does INP affect rankings?

It is part of Core Web Vitals, so it is a lightweight signal. The stronger argument is the behavioural one: unresponsive pages lose people who already arrived, and that costs more than the ranking effect.

INP, the metric that measures whether your page feels broken

Your INP is poor and you want to know what is actually causing it and what to do.

Short answer

Interaction to Next Paint measures the delay between a user action and the next visible update, across all interactions on a page, reported near the worst case. Under 200ms is good. Bad INP is almost always JavaScript occupying the main thread when the click arrives, and the cheapest fix is usually to respond immediately with something visible rather than to make the work faster.

What it measures, precisely

From the moment of input to the next frame the browser paints. It covers the whole path: waiting for the main thread, running your handler, and rendering the result. It reports near the worst interaction on the page rather than the average, because the worst one is what people remember.

Why it replaced the old metric

The previous responsiveness metric only measured the delay before the first interaction and only the input delay portion. It could look excellent on a page that was unusable after load. INP covers the whole session and the whole path, which is why scores got worse when it took over without anything actually changing.

What causes a bad score

Long tasks on the main thread. Hydration on a framework page, large bundles parsing, expensive re-renders, synchronous work in the handler itself, third-party scripts doing whatever they like. The browser is single-threaded for this work, so anything running is time your click waits.

The counterintuitive fix

Often the answer is not making the work faster. It is acknowledging the interaction immediately, with a spinner, a disabled state, a highlight, anything painted within a frame, and then doing the work. The measured delay drops because something visibly happened, and the perceived responsiveness improves for the same reason.

Break up the long tasks

Split large synchronous work so the browser can respond between chunks. Yield to the main thread. Defer anything not needed for the first interaction. This is ordinary performance engineering and it is what actually moves the metric when the acknowledgement trick is not enough.

Audit your third parties

Analytics, chat widgets, consent banners and tag managers all run on the same thread as your interface. A consent banner that blocks interaction for half a second is a compliance decision with a measurable responsiveness cost, and it is often the single largest contributor.

The behaviour it predicts

When a click does nothing for long enough, people click again, then conclude the page is broken and leave. That shows up in analytics as dead clicks, rage clicks and quick back-clicks. Those are the same event as a bad INP, seen from the user side.

Questions

What is a good INP?: Under 200ms at the 75th percentile is good, 200 to 500 needs improvement, above 500 is poor. Note that a number in the needs-improvement band is often reported loosely as poor, which is not the same thing.
Why did my score get worse without any change?: If it coincided with the metric changing from the older responsiveness measure, nothing on your site got worse. INP measures more of the session and more of the path, so many sites saw a step change on the same code.
Does INP affect rankings?: It is part of Core Web Vitals, so it is a lightweight signal. The stronger argument is the behavioural one: unresponsive pages lose people who already arrived, and that costs more than the ranking effect.

Measured, not asserted

ihatepdf.cv measured 296ms INP across 132,748 real sessions on the way to 100,542 users, against a 200ms good threshold, with 37.16% of sessions containing a dead click and 1.84% containing a rage click. Three hundred milliseconds of nothing is long enough for a person to conclude the click did not register.

Free tool for this: Log File Analyzer. No account, nothing uploaded.

Where this goes deeper

Every number on this page comes from one complete dataset: one product taken from zero to 100K+ users on search alone, with nothing spent on advertising. The full argument is Chapter 19 of the book. Five chapters are free to read.