What Is INP?

Interaction to Next Paint measures how long a page takes to show that it has understood what the user just did. The clock starts with the click, tap or key press and stops at the first frame reflecting the result. It does not measure how long the action takes to complete, but how long it takes for anything to become visible.

That distinction is the heart of the metric. A button opening a menu may need half a second to load its contents and still score well if the menu appears empty at once and fills in afterwards. Conversely, a button doing very little work scores badly if the browser happened to be busy with something else when the user pressed it.

Only three kinds of interaction count: click or tap, key press, and keyboard interaction on focusable elements. Scrolling or hovering does not count, even though janky scrolling feels just as bad. Other signals within Core Web Vitals cover that.

That detail explains why INP cannot be gamed with loading tricks. A page can arrive complete in half a second and respond terribly to the first click, because the browser is still busy running the JavaScript that came with it. Delivery speed and responsiveness are different things, and users notice the second one sooner: they expect a page to take a moment to appear, not to go mute while they are already using it.

So it helps to treat page speed as two separate questions. How long until something is visible is answered by LCP; how long until something responds, by INP. Optimising only the first leaves pages that look fast and feel heavy, and that mismatch shows up in bounce rate before it shows in any technical report.

Every measured interaction breaks into three consecutive phases, and their sum is what gets compared against the thresholds. Google rates an INP up to 200 milliseconds as good, up to 500 as needing improvement, and above that as poor. As with the other field metrics, assessment runs on the 75th percentile of real visits, so a good value on the team laptop says nothing.

Which phase dominates completely changes where the work sits. If input delay dominates, long tasks already running are the problem, and the fix lives in the tag manager and in third-party scripts. If presentation dominates, document size is the problem, and that gets fixed in the CMS template.

There is an asymmetry between the three phases worth keeping in mind. Input delay and presentation depend on the page's general state: how many scripts are running, how large the document is, what else is happening at that instant. Processing, by contrast, depends on the specific code of the button that was pressed. The first kind of problem is fixed once and improves every interaction; the second has to be fixed element by element.

In a technical SEO audit that difference decides the order of work. It pays to start with what affects the whole template, because a single correction there moves the percentile at once, while optimising one button only improves the visits that press it.

Until March 2024 the interactivity metric was First Input Delay, and the switch was not cosmetic. FID measured only the first interaction of a visit, and of that only its waiting phase, counting neither processing nor painting. The result was a metric that was easy to pass: almost every page cleared it even when it felt sluggish to use.

INP measures every interaction and all three phases, and keeps the worst. That is why many sites saw the light go from green to amber without changing anything. They did not get worse: the old rule was not measuring what it claimed to measure.

That story carries a lesson beyond speed. A metric almost everyone passes is not describing reality, it is describing its own threshold. The same holds for any KPI on an web analytics dashboard.

The change also had a practical consequence for reporting. Many client dashboards kept showing FID for months after its retirement, because the metric was hard-wired into the report template and nobody reviewed it. The result was presentations with a green light that no longer corresponded to any real assessment by Google.

It is worth reviewing any inherited KPI by the same standard: if nobody remembers when the threshold was set, it probably describes a situation that no longer exists. That holds for speed and equally for business metrics such as conversion by channel on an web analytics dashboard nobody has touched in two years.

The first step is not optimising but identifying which single interaction drags the value down. Field tools name the culprit element, and often it is exactly one: a catalog filter, a variant picker on an e-commerce product page, a dropdown menu with too many levels.

From there the levers are few and familiar. Break long JavaScript tasks apart so the browser can respond to the user between pieces. Take everything out of the event handler that the immediate response does not need. Shrink the document, because every extra node makes layout recalculation more expensive. And review which third-party scripts load through Google Tag Manager, which is usually where the problem grows without anyone deciding it.

Checking afterwards follows the same rules as the other field metrics: values in Search Console take weeks to move, so measuring the next day says nothing. And because INP touches directly what the user feels, it pays to cross-check it against bounce rate and the conversion of the affected page.

One frequent case deserves separate mention, because it resolves without touching code. Many sites load scripts through the tag manager that nobody uses any more: a heatmap tool trialled once, a replaced chat widget, a pixel from a finished campaign. Each competes for the main thread on every visit. Going through that list and deleting the dead ones is usually the cheapest improvement available.

The second cheap measure is asking what must run at load and what could wait. A heatmap or a session tool does not need to start in the first second; deferring it until after the first interaction changes nothing about what it measures and frees exactly the moment INP watches.

• Optimising the homepage while the problem sits in a product or filter template nobody measures.
• Confusing INP with the total duration of the action: what counts is when the response becomes visible, not when the work finishes.
• Testing only on desktop, when mobile-first indexing decides and older phones take several times as long for the same task.
• Adding a loading animation and calling it solved: the animation improves perception, not the metric.
• Treating the thresholds as a pass mark. Going from 480 to 320 milliseconds improves the real experience even while the label stays amber, exactly as with LCP.