First Input Delay (FID) was the Core Web Vital that measured how long a page made a user wait after their very first interaction — a click, tap, or key press — before the browser could start processing it. It was a real-user-only metric that exposed main-thread congestion during load. As of March 2024, Google retired FID and replaced it with Interaction to Next Paint (INP), so if you are auditing a site today, FID is a historical baseline, not a target.
First Input Delay (FID)
First Input Delay (FID) was a Core Web Vital that measured the delay (in milliseconds) between a user’s first interaction with a page and the moment the browser began processing the associated event handler.
What FID Actually Measured
FID captured one narrow thing: the input delay on the first interaction. When someone clicked a button or tapped a link during page load, the browser may have been busy parsing and executing JavaScript on the main thread. FID measured how long that interaction sat in the queue before the browser could even start running its handler.
Three details mattered, and most teams got at least one of them wrong:
- It only counted the first interaction. Every subsequent click, scroll, or keystroke was invisible to FID. A page could feel sluggish all day and still post a great FID.
- It only measured the delay, not the work. FID stopped its clock the instant the handler began running. If your handler then locked the main thread for 800ms, FID didn’t care — the user did.
- It was field-only. FID required a real human pressing something. Lab tools like Lighthouse couldn’t produce a true FID because there is no real user to interact, which is why Lighthouse reported Total Blocking Time (TBT) as its lab proxy instead.
FID was the metric that flattered slow sites. It scored the welcome, not the conversation — which is exactly why Google replaced it.
The old FID thresholds
These were the Core Web Vitals scoring bands while FID was active. We keep them here for historical context — you’ll still see them in old audits and CrUX exports.
| Rating | FID (75th percentile) |
|---|---|
| Good | ≤ 100 ms |
| Needs improvement | 100 ms – 300 ms |
| Poor | > 300 ms |
The “75th percentile” part is important and still applies to INP: Google scores the experience of your slower 25% of page loads, not the median. Optimizing for the average user hides your worst sessions, which are the ones that abandon.
Why FID Was Retired for INP
In March 2024, Interaction to Next Paint (INP) officially replaced FID as a Core Web Vital. This wasn’t a rename — it was an upgrade that closed every blind spot above.
| Dimension | First Input Delay (FID) | Interaction to Next Paint (INP) |
|---|---|---|
| Interactions counted | First only | All of them, reports the worst |
| What it times | Input delay before handler starts | Full delay → processing → next paint |
| Captures handler work | No | Yes |
| Captures rendering delay | No | Yes |
| ”Good” threshold | ≤ 100 ms | ≤ 200 ms |
| Status | Retired (2024) | Current Core Web Vital |
INP measures the complete round trip: input delay, the time your event handlers run, and the time the browser takes to paint the visual result. A button that highlights instantly but takes a second to actually do anything now gets penalized — correctly. If you’re still chasing FID numbers, you’re optimizing a metric Google stopped using. Point your responsiveness work at INP instead, the same way you’d treat any of the Core Web Vitals that influence SEO.
Does FID Still Affect SEO?
Not directly — FID is no longer part of the page experience signal. But the cause of bad FID is identical to the cause of bad INP: a congested main thread during and after load. So every fix that would have improved FID still improves INP, which is a live ranking input.
The practical takeaway for search ranking work: Core Web Vitals are a tiebreaker, not a primary driver. Google has been explicit that relevance and content quality win first; responsiveness is the margin that separates two otherwise-equal results. We treat it that way in audits — fix the obvious offenders, don’t chase a perfect score at the expense of content. A clean SEO content audit almost always moves the needle more than shaving 40ms off interaction latency.
How to Diagnose Slow Input (FID or INP)
The diagnostic workflow is the same regardless of which metric you’re chasing, because both come from the same root: long tasks blocking the main thread.
1. Get the field data first
Lab tools lie about responsiveness because there’s no real user. Start with real-user data:
- Chrome User Experience Report (CrUX) via PageSpeed Insights — shows your real INP distribution by page.
- The
web-vitalsJavaScript library — attribute interactions in production and ship the data to your analytics. - Search Console’s Core Web Vitals report — buckets your URLs into Good / Needs Improvement / Poor at scale.
2. Reproduce in the lab
Once you know which pages are slow, open Chrome DevTools → Performance, throttle the CPU to 4x slowdown, reload, and interact the way the metric does. Watch for long tasks — anything over 50ms shows a red flag in the flame chart. In Lighthouse, Total Blocking Time is your stand-in: high TBT almost always means high real-user input delay.
3. Trace each long task to its source
Expand the long tasks in the flame chart and read the call stack. You’re hunting for the usual suspects:
// PerformanceObserver: log long tasks in production
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// entry.duration > 50ms = a main-thread blocker
console.log('Long task:', entry.duration, entry.attribution);
}
});
observer.observe({ type: 'longtask', buffered: true });Use the Coverage panel to find JavaScript you ship but never run, and the Bottom-Up view to surface the single functions eating the most main-thread time.
How to Fix It
Ranked by how much main-thread time they typically buy back:
1. Cut the JavaScript bundle. This is the lever that moves everything. Code-split by route, tree-shake dead code, and lazy-load anything below the fold. Most “slow interaction” problems are really “we ship 600KB of JS to render a contact form” problems. Our broader take on this lives in how to make JavaScript SEO-friendly.
2. Tame third-party scripts. Tag managers, chat widgets, ad scripts, and analytics are the most common cause of blocked input. Load them with async/defer, delay them until after the first interaction, or facade them (load the real widget only on click).
3. Break up long tasks. Yield to the main thread so the browser can respond to input between chunks. The modern API is scheduler.yield(); the fallback is setTimeout or requestIdleCallback. Push CPU-heavy work into a Web Worker so it never touches the main thread at all.
4. Make first-interaction handlers cheap. Defer the heavy work. The handler should acknowledge the click immediately and schedule the expensive part asynchronously, so the next paint happens fast.
5. Use passive listeners. Mark touchstart/touchmove listeners { passive: true } so the browser doesn’t wait on them to scroll.
These are the same site-speed fundamentals we apply in every technical engagement — see how to increase website speed for the full checklist. For sites built as a progressive web app, the hydration cost of your framework is usually the single biggest line item to attack.
If you want this diagnosed and fixed properly across a large template-driven site rather than page by page, that’s exactly the kind of work our AI SEO services and core programmatic SEO builds handle at scale.
Frequently Asked Questions
Is First Input Delay still a Core Web Vital?
No. Google retired First Input Delay in March 2024 and replaced it with Interaction to Next Paint (INP). FID is now a historical metric you’ll only see in old audits and archived CrUX data. If you’re optimizing responsiveness today, your target is INP, with a “Good” threshold of 200ms or less at the 75th percentile.
What was a good First Input Delay score?
A good FID was 100 milliseconds or less, measured at the 75th percentile of real-user page loads. Between 100ms and 300ms needed improvement, and anything over 300ms was poor. These bands no longer apply to ranking — INP uses a stricter, more complete 200ms “Good” threshold that also accounts for handler execution and rendering time.
What’s the difference between FID and INP?
FID only measured the delay before the browser started processing your first interaction. INP measures the full latency — input delay, event handler runtime, and time to next paint — across every interaction on the page, then reports the worst one. INP is strictly more honest, which is why it replaced FID.
Why can’t Lighthouse measure FID or INP?
Both are field metrics that require a real human to interact with the page. Lighthouse runs in a lab with no user, so it can’t generate a true interaction. Instead, Lighthouse reports Total Blocking Time (TBT) as a lab proxy — high TBT strongly correlates with poor real-user input responsiveness, so you can use it to find problems before they hit production.
How do I fix poor input responsiveness?
Reduce main-thread work. Cut and code-split your JavaScript bundle, defer or facade third-party scripts, break long tasks into chunks that yield to the browser, and move heavy computation into a Web Worker. Start with field data from CrUX or the web-vitals library to find the slow pages, then trace long tasks in Chrome DevTools Performance to their source.