Essay

Fast load, slow click: what INP measures

INP measures the delay between a click and the page's response, and explains why a site that loads fast can still feel slow to your customer.

Contents · 4 sections

A website can load in the blink of an eye and still feel slow the moment your customer clicks something. That feeling has a name: Interaction to Next Paint, INP for short, the time between a click, tap or keypress and the first visible response from the page. Load time is about the first moment a page comes into view. INP is about everything that happens after that, every time something is clicked until the visitor leaves the site again. So a fast load time says nothing about how the site feels once someone starts working with it.

What INP measures that load time does not show

Google introduced INP in March 2024 as an official Core Web Vital alongside loading speed and visual stability, replacing an older and less complete measure of responsiveness. In Google’s explanation the threshold sits at 200 milliseconds for a good score, between 200 and 500 milliseconds a site counts as “needs improvement” and above that as slow, measured at the 75th percentile of all interactions (consulted on October 9, 2026). Those same thresholds are described in the documentation about search results (consulted on October 9, 2026).

The difference from load time is that INP only shows itself once there is interaction. A page that comes into view within half a second can still stall noticeably the moment someone presses a button, for instance because a script is running in the background at that moment that makes the click wait. For your customer that does not feel like “the page loaded fast”, but like “the site is hanging”.

A site that loads fast is not automatically a site that responds fast.

Want to know where your site stands?

Take the free check. You'll see right away what your site needs to get found more often.

What we measure on our own sites

On the websites FWRD hosts, we measure INP in the visitor’s own browser, just like load time and visual stability, aggregated across all sites together. Between July 31, 2026 and October 8, 2026 that produced 174 measurements, spread across 18 sites. The 75th percentile of those came out at 212 milliseconds, just above the 200 millisecond threshold Google applies for responsiveness.

That is not a bad figure, but it is also not a figure to leave alone. The difference between a site that stays well under the 200 millisecond threshold from Google’s explanation (consulted on October 9, 2026) and a site that sits just above it is rarely in the hosting. It is more often in what all has to happen at the same time at the moment of the click.

Where the delay usually comes from

Three things are most often the cause in practice. The first is a script that is still busy at the moment of the click itself: a chat widget initialising, a tracking pixel writing an event, a carousel recalculating. None of those scripts is visible to your customer, but they all share the same computing time with the click that arrives at that exact moment.

The second is a button or form field that makes the whole page recalculate on every keystroke, instead of only the part that changes. You barely notice that yourself on a fast laptop, and that is exactly why it only stands out when your customer types on an older device.

The third is simply too much at once: a page with ten widgets from ten different vendors never responds as a whole faster than the slowest widget among them. Each widget works on its own, but they share the same click.

What you can check yourself

You do not need a lab tool to get a first impression. Click on your own site, on an ordinary device and not on your fastest one, on the button your customer uses most: a menu, a “send request” button, a filter. Does that feel smooth, or is there a noticeable moment of nothing happens?

Then go through the third party scripts that were added at some point. Improving an existing website explains how to tackle that kind of clean up without having to rebuild the whole site. If you would rather know what hosting and technology add on top of that, you can read that back in hosting and domain.

INP does not stand on its own. The piece about why speed is not a one off job is about load time and visual stability, the two other measures that together with INP determine how a site feels. All three ask for the same discipline: not measuring once and ticking it off, but keeping an eye on it while the site is in use.

A site that loads well and responds slowly is the same disappointment for your customer as a site that loads slowly. The difference is only in the moment they feel it.

Written with AI by FWRD. Sources and figures are linked in the text.

Where are you now?

Pick what fits best. Not listed? Choose something else.