If you are still tuning your site for first input delay core web vitals scores, you are optimizing a metric Google already deleted. First input delay was retired from the Core Web Vitals set on March 12, 2024, and replaced by Interaction to Next Paint (INP). This was not a rename. FID and INP measure genuinely different things, and the switch is why so many teams watched their responsiveness score quietly regress overnight without changing a single line of code. Understanding what first input delay actually measured — and, more importantly, what it deliberately ignored — is the fastest way to understand why INP exists and what you now have to fix.
What First Input Delay Actually Measured
First input delay measured one narrow thing: the time between a user’s very first interaction with the page and the moment the browser’s main thread was free to begin processing that interaction’s event handler. Note the two hard limits baked into that definition. It only counted the first interaction of the page’s life. And it only counted the delay before processing started — not the processing itself, and not the time to paint a visible response.
The threshold was 100 milliseconds at the 75th percentile of real users. Under 100ms was “good.” The idea was reasonable in 2020: a page that was busy parsing scripts on load would block that first tap or click, and a laggy first impression predicts a frustrating session. As a first-load responsiveness proxy inside Core Web Vitals, FID did its job. The problem was everything the definition left out.
Why Almost Every Site Passed FID
By 2023, roughly 95% of sites passed the first input delay Core Web Vitals threshold in the field. When a metric passes nearly everyone, it has stopped discriminating between good and bad experiences — and that is exactly what happened. FID was easy to pass for three structural reasons that had nothing to do with a site being genuinely responsive.
- It only ever looked at the first interaction. A user’s first tap often lands during a relatively quiet moment. The tenth interaction — filtering a product grid, opening a menu, submitting a form — is where sites actually janked, and FID never saw any of it.
- It stopped counting the instant processing began. A page could have a 30ms input delay (passing easily) and then run a 400ms event handler that froze the screen. FID scored that interaction as excellent because the handler’s cost fell entirely outside the window it measured.
- It ignored rendering entirely. Even after the handler finished, the browser still had to paint the result. FID stopped the clock before that, so a visibly slow update looked instant in the data.
In other words, first input delay measured the appetizer and declared the whole meal delicious. INP was built to measure the meal.
Interaction to Next Paint: The Metric That Replaced It
Interaction to Next Paint fixes all three blind spots at once. Instead of the first interaction, INP observes essentially every tap, click, and key press across the entire visit and reports (roughly) the worst one — the single slowest interaction that a real user actually felt. And instead of stopping when processing begins, INP measures the full round trip: from the moment the user acts to the moment the browser paints the next frame reflecting a response.
The “good” threshold is 200ms or less at the 75th percentile, with 200–500ms flagged as “needs improvement” and anything above 500ms marked “poor.” Because INP captures the whole interaction and the whole session’s worth of them, the same site that comfortably passed first input delay can land in the “needs improvement” band under INP without anything on the page having changed. The site did not get slower. The measurement finally got honest.
The Three Delays Inside Every Interaction
The single most useful mental model here — and the thing FID hid from you — is that every interaction is made of three sequential delays. INP is their sum. Diagnose which one dominates and the fix becomes obvious.
- Input delay: time from the user’s action until the event handler can start, usually because the main thread is busy with another task.
- Processing time: how long your event handlers actually take to run — the JavaScript that responds to the click.
- Presentation delay: time to recalculate styles, lay out, and paint the next frame so the user sees the result.
Here is a worked micro-example. A user clicks “Add to cart.” The main thread is mid-way through a third-party analytics task, so the handler waits 40ms (input delay). The handler then runs your cart logic, fires two tracking events, and rebuilds part of the DOM, taking 210ms (processing time). Finally the browser recalculates layout for the updated mini-cart and paints it, taking 60ms (presentation delay). Total INP for that interaction: 310ms — a clear “needs improvement” result. First input delay would have reported this same click as 40ms and passed it. The 270ms the user actually waited was invisible to the old metric.
Diagnosing Which Delay Is Your Bottleneck
Most teams skip diagnosis and start “optimizing JavaScript” in general, which wastes weeks. The three-delay model gives you a decision rule instead. Pull the interaction breakdown from field data or the Chrome DevTools Performance panel and look at which segment is largest:
- Input delay dominates? Your main thread is congested, usually at page load or from a heavy recurring task. The culprit is long tasks — chunks of uninterrupted main-thread work over 50ms — often from third-party tags, hydration, or a monolithic bundle.
- Processing time dominates? Your event handlers are doing too much synchronously. This is the most common INP failure on modern JavaScript sites.
- Presentation delay dominates? Your DOM is huge or your CSS is expensive, so a single update triggers a costly layout and paint across thousands of nodes.
Fixing the wrong delay produces no movement in the score, which is why so many INP projects stall. Diagnose first, then act.
How to Fix INP, Mapped to the Three Delays
Once you know the dominant delay, the remedies are specific rather than vague performance-hygiene advice:
- To cut input delay: break up long tasks. Defer or lazy-load non-critical third-party scripts, split large bundles, and reduce main-thread work during hydration. Every long task you shorten is a window in which an interaction no longer has to wait.
- To cut processing time: do less work in the handler and do it later. Yield to the main thread with
await scheduler.yield()or asetTimeoutbreak so the browser can paint, move non-urgent work (analytics, logging) out of the critical path, and avoid forcing synchronous layout reads in the middle of writes. - To cut presentation delay: shrink what the browser has to render. Trim excessive DOM depth, use
content-visibility: autofor off-screen sections, and avoid animating properties that trigger full layout recalculation.
A useful discipline: after an interaction updates state, let the browser paint a simple acknowledgment first, then run the heavier work. Users forgive a spinner far more than a frozen screen, and INP rewards the frame that shows something happened.
Measuring It: Field Data Versus the Lab
This is where first input delay quietly spoiled a lot of teams. FID could only ever be a field metric — it needs a real user to produce the first interaction — but people got used to eyeballing a proxy in lab tools. INP has the same constraint, only sharper: there is no clean single-load lab number for it, because INP depends on which interactions real users perform and how loaded their devices are.
Treat the Chrome User Experience Report (CrUX) and your own real-user monitoring as ground truth for the 75th-percentile INP that Google uses for Core Web Vitals assessment. Use Lighthouse and the DevTools Performance panel for diagnosis — to reproduce a slow interaction and read its three-delay breakdown — not for the pass/fail number itself. Lab tools tell you why an interaction is slow; only field data tells you whether your users are actually experiencing it.
Migrating Dashboards and Reports Built on FID
Any dashboard, client report, or alert that still references the first input delay Core Web Vitals metric is now tracking a dead signal, and the migration has a predictable trap: INP numbers look worse than the FID numbers they replace. That is not a regression to apologize for — it is the same site measured honestly for the first time. Get ahead of it by reframing the story before a client notices the drop.
This is exactly the kind of technical signal that should live in an automated audit rather than a manual spreadsheet. SEO Rocket’s real-crawler site audit surfaces Core Web Vitals alongside crawlability, indexation, and on-page issues, so a shift like the FID-to-INP change shows up as a flagged item in the client dashboard instead of a surprise. The point is not to chase a green score for its own sake — it is to keep responsiveness on the same monitored list as the rankings and traffic that responsiveness quietly influences.
Where This Sits in Core Web Vitals Now
The current Core Web Vitals are three: Largest Contentful Paint (LCP) at 2.5 seconds for loading, INP at 200ms for interactivity, and Cumulative Layout Shift (CLS) at 0.1 for visual stability. First input delay is gone from that set entirely. It remains worth understanding only as the metric whose failure explains why INP is stricter — and as a reminder that Core Web Vitals thresholds are influential but modest ranking signals, meaningful mainly as tie-breakers between pages of comparable relevance and content quality. A blazing-fast page that answers the query poorly still loses. This is why SEO Rocket keeps Core Web Vitals on the same monitored dashboard as rank tracking and AI-visibility tracking rather than in a separate performance silo — the playbook proven across 1,000,000+ ranking pages treats vitals as table stakes you clear so the content can compete, not as a substitute for the content itself.
Frequently Asked Questions
Is first input delay still a Core Web Vitals metric?
No. First input delay was removed from Core Web Vitals on March 12, 2024, and replaced by Interaction to Next Paint. Any tool or report still showing FID as a current Core Web Vital is out of date, though FID data may linger in historical archives.
What is the difference between FID and INP?
FID measured only the input delay of the first interaction — the wait before processing began. INP measures the full duration (input delay plus processing plus rendering) of essentially all interactions during a visit and reports the worst. INP is both broader and stricter, which is why passing scores often drop after the switch.
What is a good INP score?
200 milliseconds or less at the 75th percentile of real users is “good.” 200–500ms is “needs improvement,” and above 500ms is “poor.” Because it is measured in the field, you need real-user data or CrUX to assess it accurately, not a single lab test.
Do Core Web Vitals actually affect rankings?
They are a genuine but lightweight signal. Core Web Vitals help decide between pages of similar relevance and quality; they will not lift a page that fails to satisfy the search intent. Clear the thresholds so performance is not a handicap, then win on content and links.
