23 Oct 25 
A page can load in a flash and still feel sluggish the moment you interact with it. That gap is what Interaction to Next Paint measures. Here is what INP is, why it exists, and how to improve it.
You have felt this even if you have never named it. A page loads quickly, looks ready, and then you tap a button and nothing happens. A half-second of dead air. You tap again, unsure if it registered, and then the menu finally opens. The page was fast to load and slow to respond, and those are two completely different things. The second one has a name now, and it is the Core Web Vital that most surprises teams who thought their fast-loading site was in the clear.
That metric is Interaction to Next Paint, or INP. Here is what it measures, why it matters, and what actually moves it.
Loading Fast and Responding Fast Are Different Problems
Most performance attention goes to loading: how quickly the page paints its content, which is what Largest Contentful Paint measures. That is important, and it is where the visitor’s first impression forms. But loading is only the first act. The moment the visitor starts interacting, tapping, clicking, typing, a second kind of speed takes over: how quickly the page responds to what they do.
INP measures exactly that. It looks at the interactions a visitor has with your page across their whole visit and reports how long the page took to visually respond, focusing on the slowest ones. A good INP means the page reacts almost instantly to taps and clicks. A poor INP means that dead-air gap, the one that makes even a beautiful, fast-loading site feel broken and cheap.
Why INP Exists (and Replaced FID)
For years the responsiveness vital was First Input Delay, which only measured the delay before the browser started processing your very first interaction. It was a narrow, forgiving metric: it captured the initial tap and ignored everything after. Plenty of sites that scored well on it still felt sluggish in real use, because the slowness showed up on the third click, not the first.
INP is the honest successor. It considers interactions throughout the visit, not just the first, and it measures the full time until the page visibly responds, not just the delay before processing begins. It is stricter and more representative, which means some sites that looked fine under the old metric have real work to do under the new one. You can read the current thresholds and definitions at web.dev/vitals.
What Actually Makes INP Bad
Almost always, the culprit is JavaScript hogging the main thread. The browser can only do one thing at a time on that thread, and if it is busy running a heavy script when the visitor taps, it cannot respond to the tap until it finishes. The gap you feel is the browser saying “one moment, I am still working.”
The usual sources are familiar once you look. Oversized JavaScript bundles that take a long time to execute. Third-party scripts, chat widgets, analytics, tag managers, doing work in the background at the exact moment the user wants to interact. Expensive event handlers that run heavy logic on every click or keystroke. And frameworks shipping more code than a mostly static page needs, which is a big reason a lean, static-first stack tends to have healthy INP almost for free.
How to Improve It
Start by measuring real users, not a lab. INP is best understood from field data, because it depends on real interactions on real devices, and a lab test that never clicks anything cannot see it. Once you know you have a problem, the work is mostly about giving the main thread room to breathe: cut and split large JavaScript bundles so less runs at once, defer or remove third-party scripts that do not earn their place, and lighten the heavy event handlers so a click does not trigger a pile of work before the page can repaint.
The theme underneath all of it is the same one that runs through every Core Web Vital: the browser has limited time and attention, and performance is the practice of not squandering it. A site that loads fast has won the first impression. A site that also responds fast keeps it, because responsiveness is what makes a product feel trustworthy in the hand, and that trust quietly feeds conversion on every single interaction.
If your site loads fine but feels sluggish to use, INP is probably why, and diagnosing exactly which scripts are eating your responsiveness is something we do for a living.