Optimizing First Input Delay (FID) for Improved User Interactivity

Is First Input Delay (FID) still a Core Web Vital?

No. First Input Delay (FID) was retired and replaced by Interaction to Next Paint (INP) as the responsiveness Core Web Vital on 12 March 2024 (web.dev). So if you came here to optimize FID, the metric to focus on now is INP, which measures the same thing more completely: how quickly your page responds when people interact with it. The good news is that the work that improved FID also improves INP, so the effort transfers directly. This guide explains what changed, what INP measures, and how to optimize it.

Key Takeaways

• FID was replaced by INP on 12 March 2024; INP is now the responsiveness Core Web Vital (web.dev).
• FID only measured the delay on the first interaction; INP measures responsiveness across the whole visit, a tougher, fairer test.
• A good INP is 200 milliseconds or less, at the 75th percentile of real visits (web.dev).
• The cause is almost always too much JavaScript blocking the main thread; the fix is reducing, deferring, and breaking up that work.

If you’ve read older guides about First Input Delay, this is the update you need: the metric changed, the target tightened in spirit, but the underlying problem (a page that’s slow to respond because the browser is busy) and its fixes are the same. The shift from FID to INP made responsiveness measurement more honest, which is worth understanding. This guide covers it as one metric in our Core Web Vitals beginner’s guide.

The table below summarises the FID-to-INP change.

What is INP and how is it different from FID?

INP (Interaction to Next Paint) measures how quickly your page visually responds across all the interactions a user makes during a visit, where FID only measured the delay on their very first interaction. That difference matters: FID was a relatively easy metric to pass because it ignored everything after the first tap, so a page could score well on FID yet still feel sluggish throughout the rest of the visit. INP closed that gap by assessing responsiveness continuously.

Concretely, INP looks at the interactions throughout a visit (clicks, taps, key presses) and reports a value representing the page’s overall responsiveness, essentially the latency of the slowest meaningful interactions. A good INP is 200 milliseconds or less, measured at the 75th percentile of real visits (web.dev). Because it covers the whole visit, it’s a tougher and more realistic test of how responsive a page actually feels.

The practical implication is that you can’t pass INP just by making the first interaction fast; the page has to stay responsive as people use it. That’s harder, but it’s also more meaningful, since it reflects the real experience. The reassuring part is that the root cause is the same one that hurt FID, too much work on the browser’s main thread, so if you optimized for FID before, you’re already on the right track for INP, which our guide to improving Core Web Vitals addresses across all three metrics.

Why do so many sites struggle with INP?

INP has a reputation as the hardest Core Web Vital to optimise, even though it isn’t the metric the most sites fail outright. As of the 2025 HTTP Archive Web Almanac, about 77% of mobile page loads achieve a “good” INP, a higher pass rate than Largest Contentful Paint at 62%, so LCP remains the most-failed Core Web Vital while INP is the one teams find hardest to move on JavaScript-heavy sites (HTTP Archive).

The reason it feels like the metric “everyone is failing” is the switch from FID. When INP replaced the lenient First Input Delay in March 2024, many sites that comfortably passed FID suddenly failed INP, because FID only ever judged the first interaction and ignored the sluggishness that followed. INP exposed responsiveness problems that were always there but never measured. That struggle is concentrated in heavily interactive, script-laden sites, ecommerce stores, dashboards, and social apps, where lots of JavaScript competes for the main thread on every click and tap. So while more pages across the web pass INP than pass LCP, if your site is interaction-heavy, INP is very likely the vital that will take the most work, which is why it deserves focused attention rather than complacency.

What causes poor interaction responsiveness?

Poor INP is almost always caused by JavaScript tying up the browser’s main thread, so the page can’t respond quickly when a user interacts. The browser handles interactions on the same single main thread that runs your JavaScript, so when that thread is busy with long tasks, interactions queue up and the page feels laggy. Almost every responsiveness problem traces back to this.

The specific culprits are long JavaScript tasks (scripts that run for a long time without yielding), too much JavaScript overall (heavy frameworks, many third-party scripts, analytics and ad tags), and inefficient event handlers that do heavy work the moment a user interacts. Third-party scripts are a frequent and underestimated cause, since each tag you add competes for the same main thread, and you often don’t control how efficiently they run.

The reason INP is harder to pass than FID was is that this main-thread congestion affects every interaction, not just the first. A page might respond fine to the first click (passing FID) but then stutter on subsequent interactions as scripts continue to run (failing INP). So the goal isn’t a fast first response; it’s keeping the main thread free enough to respond quickly throughout the visit, which means being disciplined about how much JavaScript runs and when.

How do you improve INP?

You improve INP by reducing how much JavaScript runs, deferring what isn’t needed immediately, and breaking up long tasks so the main thread stays free to respond. The aim is to keep the browser available to react to interactions rather than locked up processing scripts. Work through these in order of impact:

1. Reduce JavaScript. Ship less of it: trim unused code, question heavy frameworks and plugins, and audit third-party scripts (analytics, ads, widgets), removing or limiting those that aren’t essential. Less script means less main-thread work.
2. Break up long tasks. Split long-running JavaScript into smaller chunks that yield back to the main thread, so the browser can respond to interactions between them rather than being blocked by one big task.
3. Defer non-essential work. Load and run scripts that aren’t needed for interaction later, so they don’t compete with the user’s actions during the critical early moments.
4. Optimise event handlers and use web workers. Keep the code that runs on interaction lean, and move suitable heavy work off the main thread into web workers, so it doesn’t block responsiveness.

Measure with PageSpeed Insights and confirm with the field data in Search Console, since INP, like all Core Web Vitals, is assessed on real users. Because the cause is consistent (main-thread congestion from JavaScript), the fixes are consistent too, which makes INP tractable even though it’s a tougher metric than the FID it replaced.

How do third-party scripts hurt INP, and what can you do?

Third-party scripts, analytics, ads, chat widgets, A/B testing tools, and social embeds, are one of the biggest and most underestimated causes of poor INP, because each one runs on the same main thread your page needs in order to respond to clicks and taps (web.dev). When those scripts run long tasks, the user’s interactions queue up behind them and the page feels laggy, and you usually have little control over how efficiently a vendor’s code is written (web.dev).

A few disciplined habits keep third-party code from wrecking responsiveness:

• Audit and remove. List every third-party tag on the page and cut the ones that don’t earn their place. This is the highest-leverage fix, because the fastest script is the one you never load.
• Load late or on interaction. Defer non-essential scripts until after the page is interactive, and load heavy widgets like chat or video players only when a user actually engages, using a lightweight placeholder (“facade”) in the meantime.
• Manage tags deliberately. A tag manager helps you see and control what’s running, but don’t let it become a dumping ground that quietly piles on main-thread work.
• Move work off the main thread. Where possible, run heavy or third-party work in a web worker (tools such as Partytown can relocate some third-party scripts), freeing the main thread to stay responsive.

Because third-party code competes for the exact resource INP measures, the browser’s main thread, managing it carefully is often the single biggest INP win available, especially on sites that have accumulated tags over years.

Final thoughts

The headline is simple: First Input Delay is gone, replaced by Interaction to Next Paint in March 2024. If you set out to optimize FID, optimize INP instead, it measures the same kind of thing (responsiveness) but across the whole visit rather than just the first interaction, which makes it a fairer and tougher test.

The reassuring part is continuity: the cause of poor responsiveness hasn’t changed (too much JavaScript blocking the main thread), so the fixes haven’t either. Reduce and defer JavaScript, break up long tasks, and keep event handlers lean, and the page stays responsive throughout the visit. For the loading and stability metrics, see our guides to Largest Contentful Paint and Cumulative Layout Shift.