Interaction to Next Paint (INP) is the Core Web Vitals metric that measures how quickly your page visually responds after a user taps, clicks, or presses a key. It replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it is stricter: where FID only measured the delay before the browser started processing the very first interaction, INP measures the full response time — input delay plus processing plus rendering — across every interaction on the page, then reports roughly the worst one. A good INP is 200 milliseconds or less; anything above 500 ms is poor.
Why INP is harder to pass than FID was
FID was easy to game because it ignored almost everything that makes a page feel slow. It stopped counting the moment the browser began handling the first click, so a page that took a full second to actually update the screen could still score well. INP closes that loophole. It captures the whole journey from the user's action to the next frame the browser paints, and it looks at interactions throughout the visit — not just the first one. That means a page with one snappy hero button but a sluggish menu, filter, or "add to cart" further down will now be judged by the slow one.
Because INP is a field metric collected from real users, you cannot fully diagnose it in a lab tool alone. A synthetic run tells you a page can be fast; field data from the Chrome User Experience Report tells you whether it actually is for real people on real devices. Both matter, and they are part of the broader picture in our complete guide to Core Web Vitals.
The three parts of an interaction — and where the time goes
Every interaction INP measures breaks into three phases, and fixing INP means finding which phase is eating your budget:
- Input delay: the time between the user's action and the browser being free to run your event handler. This is almost always caused by the main thread being busy — usually long JavaScript tasks that are still executing when the user clicks.
- Processing time: how long your event handlers take to run. Heavy work fired synchronously on click — big loops, expensive DOM queries, layout thrashing — lands here.
- Presentation delay: the time to recalculate layout and paint the next frame. Large, complex DOM trees and forced synchronous layout ("layout thrashing") make this worse.
The dominant cause of bad INP for most sites is the main thread being blocked by JavaScript — either your own bundle or third-party scripts. Long tasks that hold the thread for more than 50 ms are the enemy, because any interaction that arrives during one has to wait for it to finish.
How to fix a poor INP
The fixes cluster around one idea: stop hogging the main thread, and give the browser a chance to paint. Break up long JavaScript tasks so no single task blocks the thread for long — yield back to the browser periodically so it can respond to input between chunks of work. Defer or lazy-load anything not needed for the initial interaction, and audit your third-party scripts hard, because analytics, tag managers, and chat widgets are frequent INP killers; our guide on setting a third-party script performance budget walks through capping their damage.
On the handler side, do the minimum synchronous work needed to give visual feedback, then defer the heavy lifting. If a click triggers an expensive update, paint an immediate acknowledgment — a loading state, a disabled button — and move the costly computation off the critical path so the user sees a response fast. Reduce DOM size and avoid reading layout properties in the middle of writing them, which forces the browser to recalculate synchronously. And remember that INP is device-sensitive: a fix that looks fine on your development laptop may still fail on the mid-range phones most of your real users carry.
Why INP matters beyond the score
INP is a ranking signal as part of the page experience picture, but the deeper reason to care is that it measures felt responsiveness — the difference between an interface that reacts and one that hesitates. A poor INP correlates directly with the frustration that drives people to abandon a page. And while AI crawlers do not "click" your buttons, a page that is heavy enough to blow your INP budget is usually heavy enough to slow crawling and rendering too, which is its own visibility problem covered in our broader performance optimization guide.
Start by finding out whether you have an INP problem at all, and on which interactions. Measure with field data, reproduce the slow interaction, and attribute the time to input delay, processing, or presentation before you start changing code. To get a fast read on your site's Core Web Vitals and the crawl and rendering issues sitting underneath them, run the free CheckMy.site scanner.