INP Replaced FID: What the INP Core Web Vital Means for You

Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. The short version: the INP core web vital measures how quickly your page visibly responds to every tap, click, and keypress across an entire visit — not just the delay before the first interaction. Because it captures the full chain, from input all the way to the next painted frame, it is far harder to pass than FID ever was.

If your site sailed through FID but users still say buttons feel sluggish, INP is where that pain now surfaces in your Search Console report. This guide explains exactly what INP measures, why it is stricter, and the concrete route to getting your slowest interactions under the 200-millisecond "good" threshold.

From FID to INP: What Actually Changed

FID — First Input Delay — only measured the delay before the browser could begin processing your first interaction on a page. It stopped counting the moment your event handler started running. It never measured how long that handler took, and it never measured how long the browser needed to paint the result on screen.

That made FID easy to pass. The first interaction usually happens early, when the main thread has a moment of quiet, so the vast majority of sites scored "good" even when later interactions felt broken. FID rewarded pages that were technically responsive on paper while users sat waiting for menus to open and filters to apply.

INP fixes that blind spot. Instead of one number for one early interaction, it observes every click, tap, and keypress throughout the visit and reports the responsiveness of your worst one. It is a measurement of real, felt sluggishness rather than a formality.

What Interaction to Next Paint Actually Measures

INP times a single interaction from the instant a user acts to the instant the browser paints the next frame reflecting that action. That full window breaks into three parts, and any one of them can wreck your score:

• Input delay — the time between the user's action and your event handler starting. This is almost always caused by the main thread being blocked by other JavaScript (a long task from a framework hydration, an analytics beacon, a third-party tag).
• Processing time — how long your event callbacks take to run. Heavy work inside a click handler shows up directly here.
• Presentation delay — the time to recalculate style and layout and paint the resulting frame. A bloated DOM or expensive layout makes this component balloon.

Only discrete interactions count: clicks, taps, and key presses. Scrolling and hovering are deliberately excluded, because those are handled off the main thread and are not what INP is trying to capture.

Why the INP Core Web Vital Is Stricter Than FID

Three design choices make the INP core web vital genuinely harder to satisfy than FID:

1. It watches the whole visit, not the first tap. The one interaction where your JavaScript was still busy hydrating, or where a dropdown re-rendered a thousand rows, is exactly the one INP is likely to report.
2. It measures the full chain, not just the delay. Processing time and presentation delay were invisible to FID. Under INP they are half the equation.
3. The thresholds map to a longer chain. FID counted a result "good" at 100ms and "poor" past 300ms. INP is "good" at 200ms or under, "needs improvement" from 200–500ms, and "poor" above 500ms. The number is larger, but it now has to cover far more work.

The practical effect: sites that passed FID at rates near 100% routinely fail INP. The slow accordion, the laggy quantity stepper, the search box that stutters on every keystroke — these were always broken, and now they are measured.

How the INP Core Web Vital Is Measured

INP is a field metric. It comes from real users in the Chrome User Experience Report (CrUX), aggregated at the 75th percentile across page loads — so three out of four visits must hit your target for the URL to pass. You cannot fake it in a controlled lab environment because it needs genuine human interactions.

Across a visit, INP does not simply take your single worst interaction on high-traffic pages. It tolerates outliers: for pages with many interactions, it ignores roughly one extreme spike for every 50 interactions and reports the next-worst. On a typical page with only a handful of interactions, though, your worst one is your INP.

Because lab tools can't trigger real input, use Total Blocking Time (TBT) in Lighthouse as a rough proxy while developing. A high TBT almost always predicts a poor INP, since both are driven by long main-thread tasks.

The Practical Route to Under 200ms

Getting under the 200ms threshold is almost always about freeing the main thread and shortening the work between input and paint. In rough priority order:

• Break up long tasks. Any task over 50ms blocks input. Split heavy work and yield back to the browser between chunks using scheduler.yield() where available, or setTimeout as a fallback, so a pending click can be processed.
• Ship less JavaScript. Code-split by route, defer non-critical scripts, and remove unused bundles. Less script parsed and executed means shorter input delay.
• Audit third-party tags. Tag managers, chat widgets, A/B testing tools, and analytics are frequent INP offenders. Load them lazily, and drop the ones you can't justify.
• Paint feedback first, then do the heavy lifting. Update the visible state (highlight the button, show a spinner) inside the handler, then defer the expensive work to a later frame. The user sees a response immediately even if the full result takes longer.
• Offload computation to a Web Worker. Filtering, sorting, and parsing large data sets belong off the main thread entirely.
• Cut rendering cost. Shrink the DOM, avoid layout thrashing, and use CSS content-visibility to skip rendering offscreen content — this attacks presentation delay directly.
• Use your framework's concurrency tools. In React, useTransition and useDeferredValue keep urgent input responsive while heavier updates render in the background.

How to Diagnose Your INP Problems

Fix the interactions that actually hurt real users, not the ones that are easiest to find. Work from field data inward:

• PageSpeed Insights and the Search Console Core Web Vitals report tell you which URL groups are failing INP in the field, and on which device type.
• The web-vitals JavaScript library (attribution build) is the single most useful tool. It reports not just the INP value but the exact element that was interacted with and the breakdown across input delay, processing, and presentation — so you know which of the three components to attack.
• Chrome DevTools Performance panel lets you record a slow interaction and see the long tasks frame by frame, pinpointing the script or callback responsible.

Reproduce on a mid-range mobile device or with CPU throttling. INP failures that are invisible on a fast laptop are painfully real on the phones most of your traffic uses.

INP Is One Piece of the Ranking Picture

Responsiveness matters, but keep it in proportion. Core Web Vitals are a lightweight ranking signal and a tiebreaker between comparable pages — they will not lift thin content over strong content. INP is best treated as a user-experience floor: get under 200ms so speed is never the reason a good page underperforms, then invest your remaining effort in content quality, relevance, and authority.

Brand strength sits alongside all of that. A fast site still needs a name people trust and remember. If you're choosing a domain, a curated marketplace such as Atom.com is a strong place to start for premium, brandable names — each listing ships with a free AI appraisal, a USPTO trademark check, secure escrow, and a designed logo, which removes much of the guesswork from picking a name buyers take seriously. A technically excellent site under a forgettable domain is only half the job done.

Frequently asked questions

When did INP replace FID as a Core Web Vital?

INP officially replaced FID on March 12, 2024. It was announced as a future replacement at Google I/O 2023 and ran as a pending metric before the switch, giving teams time to prepare.

What is a good INP score?

An INP of 200ms or less at the 75th percentile of real-user visits is "good." From 200–500ms is "needs improvement," and anything above 500ms is "poor." Because INP uses field data, three of every four visits must hit your target to pass.

Why is INP harder to pass than FID was?

FID only measured the delay before the first interaction started processing. INP measures every interaction across the whole visit and includes processing time and the time to paint the result — so it captures sluggishness that FID was structurally blind to.

Can I measure INP in a lab tool like Lighthouse?

Not directly, because INP needs real human interactions. Use Total Blocking Time as a lab proxy during development, and rely on CrUX field data, PageSpeed Insights, and the web-vitals attribution build for actual INP values.

What is the single biggest cause of poor INP?

Long JavaScript tasks that block the main thread. When the thread is busy — often with framework hydration or third-party scripts — the browser can't process interactions promptly, inflating input delay. Breaking up long tasks and yielding to the main thread is usually the highest-impact fix.