INP Replaced FID: Core Web Vitals Shift

First Input Delay is gone. As of its rollout, Interaction to Next Paint is the Core Web Vital for responsiveness, and the swap is not cosmetic. FID measured a sliver of one interaction; INP measures the whole responsiveness of every interaction across the visit. Many pages that comfortably passed FID now fail INP, and the reason is that INP finally measures the thing users actually feel: the lag between clicking and seeing something happen. Here is what changed and what it means for your rankings.

TL;DR: INP replaced FID as a Core Web Vital. FID measured only the input delay before the first interaction began processing; INP measures the full cycle — input, event handling, and the next paint — across all interactions, reporting a value near the worst one. The good threshold is 200 ms at the 75th percentile of field data. Pages that passed FID often fail INP because slow handlers, long main-thread tasks, and heavy DOM updates now count. VisibilityIQ reconciles CrUX field data with lab measurements and pinpoints the interactions dragging your score.

What changed and why it is stricter

FID measured one narrow thing: the delay between a user’s first interaction and the moment the browser began processing the corresponding event handler. It captured input latency but stopped there — it did not measure how long the handler ran, and it did not measure whether the screen updated. A page could begin processing quickly, then spend hundreds of milliseconds in a slow handler and a heavy re-render, and still post an excellent FID. The metric measured the doorway, not the room.

INP measures the room. It tracks the full interaction: from the input event, through all the event processing, to the next paint that reflects the result on screen. And it does not look at the first interaction alone — it observes interactions throughout the entire page visit and reports a value at or near the worst one. That dual expansion, from one interaction to all of them and from input delay to the complete cycle, is why INP is a far more honest measure of responsiveness and a far harder bar to clear.

The thresholds: 200 milliseconds or below is good, 200 to 500 needs improvement, and above 500 is poor, all evaluated at the 75th percentile of real-user field data. Because the reported value tracks the worst interaction, a single slow click can fail an otherwise responsive page — which is exactly why our site audit treats INP as a field-data finding scoped to the worst observed interactions rather than an average that hides them.

Why your FID pass does not transfer

If your pages passed FID, do not assume they pass INP. The pass-to-fail transition is common and predictable, because the interactions INP exposes were always there — FID simply did not measure them.

The usual culprits are slow event handlers that run heavy JavaScript synchronously on click, long tasks that monopolize the main thread and delay both processing and paint, and large DOM updates that force expensive layout and rendering after an interaction. Under FID, all of these were invisible as long as the initial input delay was short. Under INP, they are the score. A click that triggers a 300-millisecond handler and a full re-render posts a poor INP no matter how quickly processing began.

This is also where field and lab measurement diverge sharply, and the divergence misleads teams. Lab tools simulate a page in a controlled environment and can miss the interaction patterns and device constraints of real users. INP is fundamentally a field metric — it is built from actual interactions on actual devices — and Google ranks on that field data, not your lab numbers. Optimizing against a clean lab score while real-user INP stays poor is a trap our audit is built to catch: it reconciles the CrUX field data Google actually uses against lab measurements and surfaces the gap, so you fix what users experience rather than what your test harness reports.

How INP fits the ranking picture

Core Web Vitals are a ranking signal, and INP is now the responsiveness member of the trio alongside LCP for loading and CLS for visual stability. The weight is real but proportionate: vitals are a tiebreaker and an experience signal, not a substitute for relevance and the indexation fundamentals. A page that is not indexed, carries an accidental noindex, or fails render parity has problems that dwarf any INP gap — which is why project law ranks vitals as mid-weight, behind crawlability, canonical correctness, and parity. Fix the things that determine whether you are in the index at all before you tune the milliseconds. For sites with large URL footprints, crawl budget and crawl waste sit in that same must-fix tier — a slow server both shrinks your effective crawl capacity and drives poor INP on real users, so the overlap is direct.

That ordering said, INP matters most where engagement and conversion live: interactive product pages, search-and-filter interfaces, configurators, and any template where users click their way through a task. On those pages a sluggish INP is felt directly and compounds with abandonment. The right move is to prioritize INP work on your highest-value interactive templates rather than chasing a uniform score across pages no one interacts with.

How to diagnose and fix INP

Start from field data, because that is what is scored. Pull your INP from CrUX, segmented by template and device, and identify which interactions and which pages post the worst values — the score lives in the tail, so the tail is where you look. Then attribute each slow interaction to its cause: a long-running event handler, a main-thread task blocking processing, or a heavy DOM update delaying the paint.

The fixes follow the attribution. Break long tasks into smaller chunks and yield to the main thread so the browser can paint between work units. Move non-urgent work out of the interaction’s critical path — defer it, debounce it, or push it off the main thread with a web worker. Reduce DOM update cost by minimizing the nodes touched per interaction and avoiding layout thrashing. Trim third-party scripts that inject long tasks you do not control. Each of these targets the worst interactions specifically, because lowering the tail is what moves the 75th-percentile number Google reads.

If you are comparing tools, our comparison with Ahrefs details why a vitals score built on lab data alone is misleading for INP: without the CrUX field reconciliation, you optimize a number Google does not rank on and miss the real-user interactions that decide your score.

Why the field-versus-lab gap is wider for INP than for LCP

Every Core Web Vital has a field-versus-lab divergence, but INP’s is the widest, and understanding why prevents wasted effort. LCP and CLS are substantially about how the page loads, which a lab tool can simulate with reasonable fidelity on a fixed device and connection. INP is about how the page responds to interactions, and interactions are inherently user-driven: which element a user clicks, in what order, on what device, while what else is happening on the page. A lab tool either does not interact at all or fires a scripted interaction that bears little resemblance to real usage, so its INP estimate is at best a hint and at worst actively misleading.

The consequence is a failure pattern I see repeatedly. A team runs a lab audit, sees a passing or near-passing responsiveness number, and concludes INP is fine — while the CrUX field data Google actually ranks on shows a poor INP driven by an interaction the lab never exercised. The fix is not to trust the lab number for INP. Use lab tools to reproduce and debug a specific slow interaction once you have identified it from the field, but let the field data tell you which interactions and pages to investigate. Inverting that order — letting lab numbers set priorities — is how teams optimize hard and move nothing, because Google scores the field.

Where to spend your INP effort first

INP work has sharply diminishing returns if applied uniformly, so sequencing matters. Begin with the templates that combine high traffic with heavy interaction, because that intersection is where a poor INP both occurs and costs the most: search and filter pages, product configurators, interactive tables, multi-step forms. A static article page with one outbound link has little INP surface and rarely needs attention; a faceted catalog where users click through dozens of filters is where milliseconds compound into abandonment.

Within those templates, target the worst interactions specifically rather than averaging across all of them, since the score tracks the tail. Identify the single slowest interaction type on the template — often one heavy handler or one expensive re-render — and fix that before chasing marginal gains elsewhere. The combination of the right templates and the worst interactions within them concentrates effort where it moves the 75th-percentile field number, which is the only number that changes your ranking signal. Spreading the same effort evenly across every page is how INP projects stall: a lot of work, no measurable shift, because the worst interactions on the busiest templates were never the focus.

The bottom line

INP replaced FID because FID measured a fraction of one interaction while users live in the full responsiveness of all of them. The new metric is stricter, it is a field measurement, and many FID-passing pages now have genuine work to do on slow handlers, long tasks, and heavy DOM updates. Keep it in proportion — indexation and parity come first — but on your interactive, high-value templates, diagnose INP from real-user field data, fix the worst interactions, and you align your rankings with the responsiveness your users actually feel.