NightshiftDirect

Glossary

Interaction to Next Paint (INP)

Interaction to Next Paint is a measure of how quickly a page responds when a visitor clicks, taps or types: the time from the action until the page shows its next change on screen, reported as one value for each page view.

By NightshiftDirect Research. Published . Updated .

Which actions it times

Google's web.dev documentation counts three kinds of interaction: clicking with a mouse, tapping a touchscreen and pressing a key. Scrolling and hovering are left out (web.dev: INP).

For each interaction, the clock runs from the moment the visitor acts until the browser paints its next frame, the first chance it has to show that something happened. That covers the wait before the page's code starts to respond, the time the code takes, and the wait before the new frame appears. The page's INP is worked out when the visitor leaves, as one figure that their interactions all, or very nearly all, stayed beneath (web.dev: INP).

It replaced First Input Delay, which timed only the wait before the first interaction (web.dev: INP). A page could pass that and still stall on the third tap, which INP now counts.

How quick is quick enough?

At the 75th percentile of page loads, an INP of 200 milliseconds or less is good, over 500 milliseconds is poor, and anything between the two needs improvement (web.dev: INP). The good line is the same one the Web Vitals guidance sets for responsiveness (web.dev: Web Vitals).

INP and your place in Search

INP is one of the three Core Web Vitals. Google recommends good scores, and its Search documentation says they align with what its core ranking systems seek to reward (Google Search Central). It also says good results in its Core Web Vitals reports do not guarantee top rankings (Google Search Central).

The plainer reason to fix a slow INP is the customer who is ready to book and taps a button that does nothing.

Why a tap waits

The first part of every interaction is the input delay, the wait before the page can start to respond. Other work on the browser's main thread stretches it, and scripts loading while the page loads are one of the things that do. A large script can keep the browser busy in long tasks, and a tap that lands during one has to wait for it to finish (web.dev).

E2 is the scan's check on this measure. Heavy scripts are the usual cause, and chat widgets, tracking code and page builders are the ones to look at first. Cut any you no longer use and defer the rest. E6 is a loading check. It flags a homepage with several scripts in its head that must load before anything is drawn, and those are worth a look when taps feel slow as well.

How the scan reads it

INP needs real interactions to time. So the scan takes it from real visitors, through Google's Chrome UX Report, as long as your site gets enough traffic to appear there. A quieter site gets a single lab test instead, which gives no reading for responsiveness, and E2 goes unchecked in that report (what the free scan does not measure).

Other lab tools share the gap. Some report no INP at all, because they only watch the page load without anyone clicking anything (web.dev: INP).

What the free scan checks

Questions

Why does my speed test show no INP?

A test that only loads the page has no tap to time, so it has nothing to report for INP. Check it by hand instead: tap through your own pages on an ordinary phone while they load, and note any button or menu that lags.

What is a long task, and why does it slow my buttons?

A long task is a stretch of work, such as running a large script, during which the browser cannot respond to anything else. A tap that arrives in the middle of one waits until it ends (web.dev). That is why a menu can feel dead just after a page opens and fine a moment later.

Will removing my chat widget fix a slow INP?

It may help, if the widget's script is what keeps the browser busy. Take it off, then tap through the same pages on the same phone. If the lag is gone, decide whether the widget earns its place. If nothing changes, the delay is coming from somewhere else, and the widget can go back. Either way, the real-visitor figure moves only as new visits add up, so give it time before you judge by it.

Where this fits in our work

We handle this as part of Web design and hosting: A fast, conversion-first website built on your own accounts, then hosted, backed up and kept current.

Related reading

Posts that use this term

Related terms

Sources