What you'll learn
Quick Answer
INP (Interaction to Next Paint) officially replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. Unlike FID, which measured only the delay before the browser started handling the very first interaction, INP measures the full duration of every interaction on the page, input delay, event processing, and the time until the next frame paints, then reports a high-percentile value across the visit. A score of 200ms or under is good, 200 to 500ms needs improvement, and anything over 500ms is poor.
What INP Actually Measures
INP stands for Interaction to Next Paint. For every click, tap, or key press a visitor makes on your page, it measures the time from the moment they interact to the moment the browser actually paints the next frame in response, the full round trip, not just the start of it.
That total breaks into three pieces, per Google's own definition: input delay (time before your event handler even starts running, usually because the main thread is busy with something else), processing time (how long your handler and any resulting work actually take), and presentation delay (time from finishing that work to the browser painting the result). INP is effectively the worst of these totals across the page's lifetime, measured at a high percentile of all interactions rather than the single slowest one, so one rare outlier doesn't dominate the score.
Why FID Wasn't Enough
FID (First Input Delay), the metric INP replaced, only measured the first part of that: the delay before the browser started processing the very first interaction on the page. It never measured how long the handler took to run, and it ignored every interaction after the first one entirely.
That left an obvious gap. A page could score a perfect FID and still be frustrating to use, buttons that take a full second to visibly respond after being tapped, provided the browser at least started handling that tap quickly. FID measured the twitch of a reaction; it said nothing about whether the interaction actually finished doing anything a user could see.
INP became a stable Core Web Vital on March 12, 2024, and FID was deprecated and removed from the Core Web Vitals program that same day. It's no longer part of how Google Search Console or PageSpeed Insights scores a page.
The Real Thresholds
Per Google's published thresholds, measured at the 75th percentile of a page's real-world visits across mobile and desktop:
- Good: 200 milliseconds or less
- Needs improvement: between 200 and 500 milliseconds
- Poor: above 500 milliseconds
The 75th-percentile detail matters more than it looks: your average interaction speed isn't what gets scored. A page can feel snappy most of the time and still fail INP if one in four interactions, a slow filter, a laggy modal, an unresponsive dropdown, crosses into "poor" territory, because that slower quarter, not the typical case, is what the percentile captures. That's also why INP can flag a problem a quick manual test never turns up: it takes real visitors, on real devices, hitting that one slow interaction repeatedly in the field for it to matter to the score.
What Actually Makes INP Bad
In practice, INP problems trace back to a small set of causes:
- Long JavaScript tasks blocking the main thread. If a script is mid-execution when someone clicks, the browser can't even start the click handler until that task finishes; this shows up as input delay.
- Expensive event handlers. Heavy state updates, large re-renders, or synchronous work inside a click handler all extend the processing time directly.
- Layout thrashing. Reading a layout property, like
offsetHeight, right after writing a style change forces the browser to recalculate layout synchronously, adding real, measurable delay before the next paint. - Third-party scripts. Ad tags, analytics, and chat widgets often run on the main thread and are a common source of the exact long tasks that INP penalizes, frequently outside your own code entirely.
Measuring It and What to Fix First
Field data, real visitor interactions, is what actually gets scored, and Chrome's User Experience Report (CrUX) is where Google Search Console and PageSpeed Insights pull it from. In Chrome DevTools, the Performance panel records INP directly for a session, breaking a slow interaction down into its input-delay, processing, and presentation-delay pieces so you can see which part is actually the problem before trying to fix it.
The highest-leverage fix is usually breaking up long tasks: instead of one function running for 300ms uninterrupted, yield back to the browser periodically so the main thread stays free to handle the next paint sooner. Chasing the visually slowest-looking interaction in a manual click-through is a reasonable place to start, but it's the field data at the 75th percentile that actually decides the score. A page that feels instant to whoever is testing it on a fast laptop can still have a poor INP in the field, since real visitors bring slower devices, background tabs, and flakier connections that a manual test on a dev machine never reproduces.