INP: why a fast site can still feel slow

3 min readspeedCore Web VitalsUX

The page loaded in a second, yet the button answers half a second later. Since 2024 Google has measured exactly that - and plenty of sites proud of their speed fail it.

You tap «Add to cart» - and nothing. Half a second of silence. Then the button finally comes to life. You did not have time to think «this site is slow», but something stuck. Since March 2024 Google has measured exactly that something, as a number of its own.

What INP is

Interaction to Next Paint - the time from something you do to the moment the screen responds to it. A click, a tap, a keystroke - how many milliseconds pass before you see the result. INP replaced the old FID metric, which only measured the delay of the very first interaction and so missed most of the real problems.

  • Up to 200 ms - good: the response feels instant
  • 200 to 500 ms - needs work: people notice the pause
  • Over 500 ms - poor: the site feels broken

It is not an average but the 75th percentile of real visitors, from Chrome's data. So if a quarter of your visitors on older phones wait a whole second, your INP is poor - even if everything flies on your laptop.

Why fast loading does not save you

Load speed and response speed are different things. A page can arrive in a second, and then the browser spends several more seconds digesting JavaScript: analytics, a chat widget, ad pixels, a slider, animations. While it is busy, it cannot answer your tap. The button is already drawn, but it is still dead.

A page that looks ready but does not respond is worse than one that takes longer to load.

Where poor INP comes from

  • Third-party scripts: chat widgets, trackers, pixels - each wants to run first
  • Page builders shipping hundreds of kilobytes of JavaScript to every page
  • Heavy handlers: one button that recalculates half the page
  • Animations in JavaScript where CSS would have done
  • Weak phones: what takes 50 ms on a flagship takes 300 on a budget handset

What to do about it

First, measure it on real people rather than on your own computer. Search Console has a Core Web Vitals report built on field data, and PageSpeed Insights shows the same data at the top, above the lab test. The lab test itself does not measure INP at all - there is nobody there to tap anything.

Then remove or defer third-party scripts. A chat widget that a handful of people ever open does not need to load with the page. Analytics can wait until the visitor starts doing something. One step like that often does more than a week of optimising your own code.

And break up long tasks. If a tap kicks off heavy work, show a response first - highlight the button, show a loading state - and do the heavy part right after. People need to see they were heard. They will wait for the rest.

Why it is worth money

INP is part of Core Web Vitals, which are among the signals Google uses to assess pages. But something else matters more. The pause after a tap is exactly the moment someone decides whether to trust the site. Especially in the cart and the enquiry form - the places where they have very nearly become a customer.