FID measured a single narrow window: the delay between when a user’s first interaction reached the browser and when the browser was able to begin running that interaction’s event handler. It said nothing about how long the handler itself took to run, nothing about how long it took the browser to paint the resulting visual update, and nothing about any interaction after the first one. INP replaces that with a measurement of full interaction latency (input delay, processing time, and presentation delay combined) across every click, tap, and key interaction for the entire lifetime of the page, then reports a single high-percentile value as the page’s score. The difference isn’t just “more interactions counted,” it’s a difference in what portion of the interaction’s cost is actually being measured at all.
Mechanism
FID’s definition was deliberately narrow because of what it was technically able to observe. It captured only the delay before the first event handler could start running, meaning if a click handler took 50ms of input delay to begin, but then ran for 400ms of blocking JavaScript before the browser could render feedback, FID reported roughly 50ms while the actual experience of the interaction was closer to 450ms or more. FID could never see this because it was, by design, an input-delay-only metric, and it structurally couldn’t measure anything past the first interaction, since real user monitoring can’t observe a “delay” for interactions that never got measured infrastructure for beyond the first one on the page.
INP is built around the full interaction lifecycle, split into three named phases, per web.dev’s documentation. Input delay is the time from when the OS registers the user’s action to when the browser can start executing that interaction’s first event handler callback, which is roughly analogous to what FID measured, but only as one-third of the picture. Processing time is the total time the browser spends running every callback tied to that interaction: JavaScript event handlers, state updates, DOM reads and writes, anything synchronously triggered by that user action. Presentation delay is the time after all callbacks finish until the browser actually paints the next frame reflecting the result, which includes style recalculation, layout, paint, and compositing work, and can be substantial on pages with large DOM trees or expensive rendering pipelines. INP sums all three phases for every qualifying interaction across the page’s session, then takes a high percentile of those values (effectively close to the worst typical interaction, with outlier trimming on pages with many interactions) as the reported metric.
The other structural difference is scope across time. FID existed only for the first interaction because that was the interaction most likely to be delayed by initial page load contention (parser-blocking scripts, hydration, third-party tags), and it was treated as a proxy for “is the main thread busy when the user first tries to do something.” INP explicitly rejects the idea that the first interaction is uniquely representative, because a single-page app, for instance, can be perfectly responsive on first load and then degrade badly after several state updates have bloated memory or after a expensive re-render pattern kicks in on the fifth click. INP is a same-page-lifetime measurement precisely because responsiveness problems are often not front-loaded.
INP officially replaced FID as a Core Web Vital on March 12, 2024, after roughly two years as an experimental, then pending, metric, and FID was removed from Search Console and CrUX-based tooling on that same rollout, with about a six-month tail for tools like PageSpeed Insights to finish the transition.
| Dimension | FID | INP |
|---|---|---|
| What it measures | Delay before first handler starts | Full latency: input delay + processing + presentation |
| Which interactions | First interaction only | All qualifying interactions over the page's lifetime |
| Reported value | Delay for that one interaction | High percentile across all observed interactions |
| Rendering cost captured | No | Yes (presentation delay phase) |
| Handler execution captured | No | Yes (processing time phase) |
| Core Web Vital status | Retired March 12, 2024 | Current Core Web Vital |
| Good threshold | Under 100ms | 200ms or less |
Practical implication
Optimizing for INP requires attention to all three phases, not just the input-delay work that mattered under FID. Reducing input delay still means breaking up long tasks and deferring non-critical JavaScript so the main thread is free when a user acts. But reducing processing time means auditing what actually runs inside event handlers themselves, deferring non-essential work (analytics calls, non-visual state updates) off the critical interaction path via things like scheduler yielding or requestIdleCallback-style patterns. And reducing presentation delay means addressing what FID never touched at all: DOM size, layout complexity, and expensive style recalculation triggered by the interaction’s resulting re-render. A page that scored well on FID because its first click was fast can still score poorly on INP if later interactions trigger heavy re-renders, which is exactly the responsiveness gap INP was introduced to close.
