First Input Delay (FID) Was Replaced by INP

Short answer: First Input Delay (FID) measured how long the browser took to start responding to a visitor’s first click, tap or key press. It is no longer a Core Web Vital. Google replaced FID with Interaction to Next Paint (INP) on 12 March 2024, and Chrome ended FID support on 9 September 2024. If you care about responsiveness for SEO today, measure and improve INP, not FID.

48% to 43%Share of mobile sites with good Core Web Vitals when measured with FID versus INPHTTP Archive Web Almanac, 2024

90%of a user’s time on a page is spent after it loads, according to Chrome usage data, which FID largely ignoredweb.dev, 2024

200 msThe INP threshold for “good” at the 75th percentile, replacing FID’s 100 msweb.dev, 2024

9 Sept 2024The date Chrome stopped guaranteeing FID data in its tools and APIsweb.dev, 2024

This page is for site owners, developers and SEOs who have met First Input Delay in an old audit, a plugin, a course or a client report and want to know what to do with it. You will learn what FID measured, why Google dropped it, exactly how INP differs, and how to move your reporting and your fixes across without losing the work you already did. Most of the many guides ranking for “first input delay” still describe FID as a current metric. It is not, so treat any advice built around a 100 ms FID target as out of date.

For the full guide to diagnosing and fixing the current metric, read my Interaction to Next Paint (INP) guide. This page covers the history and the switch.

What was First Input Delay?

First Input Delay was the time between a visitor’s first interaction with a page (a click, a tap or a key press) and the moment the browser’s main thread was free to begin running the event handlers for it. It was expressed in milliseconds and collected only from real Chrome users, which made it a field metric: you could not get a true FID score from a lab test.

FID existed because pages often look ready before they are. If the browser is still parsing and running a large JavaScript bundle when someone taps the menu button, nothing happens until that work finishes. FID captured that waiting time, but only for the first interaction, and only the wait, not the work that followed.

What counted, and what did not

Counted: clicks, taps and key presses, the discrete actions where a person expects an immediate response.
Not counted: scrolling and zooming, which the browser handles differently. These are still excluded from INP.
No interaction, no score: if a visitor read the page and left without clicking anything, that visit produced no FID value at all.

The old FID thresholds

Rating	FID at the 75th percentile of page loads
Good	100 ms or less
Needs improvement	More than 100 ms, up to 300 ms
Poor	More than 300 ms

Timeline: from FID to INP

May 2020: Google announced Core Web Vitals: Largest Contentful Paint for loading, FID for interactivity and Cumulative Layout Shift for visual stability.
June to August 2021: the page experience update rolled out on mobile with Core Web Vitals as a signal. Desktop followed in early 2022.
May 2022: INP was introduced as an experimental metric.
May 2023: Google announced INP would replace FID as a Core Web Vital the following March.
12 March 2024: INP officially became a Core Web Vital and FID was retired.
9 September 2024: Chrome ended FID support. As the Chrome team’s launch post explained, tools and the CrUX and PageSpeed Insights APIs no longer guarantee FID data after that date.
May 2025: version 5 of Google’s web-vitals JavaScript library removed the deprecated onFID() function.

Rather have an expert do this for you?

Hand it over and get back to running your business.

Hand it over to me

Why Google replaced FID with INP

FID had three blind spots that made it a weak measure of how responsive a page actually feels:

It only looked at the first interaction. A product page could respond quickly to the first tap and then freeze every time someone opened a filter, changed a size or typed in the search box, and still pass.
It only timed the input delay. The clock stopped when the event handler started. A handler that ran for 400 ms, and the time the browser then took to draw the result, were invisible to FID.
Too many sites passed easily. Because the first interaction often happens after the heaviest loading work is done, FID rarely separated sluggish pages from fast ones.

INP fixes all three. It observes every click, tap and key press during the visit and times each one from the input until the next frame is painted. The 2024 Web Almanac shows the effect: with FID, 48% of websites would have had good Core Web Vitals on mobile, but with INP that figure drops to 43%. On desktop the result was 54% either way, which tells you the problem is mostly mobile, where processors are slower and JavaScript costs more. My guide to mobile SEO optimisation covers the wider picture.

FID vs INP: what changed

	First Input Delay (retired)	Interaction to Next Paint (current)
Interactions measured	Only the first one	All clicks, taps and key presses during the visit
What is timed	Input delay only	Input delay, processing time and presentation delay until the next paint
Value reported	The first interaction’s delay	Close to the slowest interaction; one outlier is ignored for every 50 interactions
Good	100 ms or less	200 ms or less
Poor	More than 300 ms	More than 500 ms
Lab proxy	Total Blocking Time	Total Blocking Time, plus recorded interactions in DevTools
Status	Retired March 2024; support ended September 2024	Core Web Vital since March 2024

INP’s thresholds look looser, but it measures far more of each interaction and far more interactions, so it is the harder metric to pass. The web.dev INP documentation sets out these thresholds and the outlier rule in full.

Worked example: why a page passed FID and fails INP

Imagine a category page on a clothing shop. The visitor’s first tap is on a cookie banner after the page has finished loading; the main thread is idle, so the input delay is 20 ms and FID records 20 ms, comfortably good. Next they tap “Filter by size”. The handler re-renders 60 product cards and a tracking script fires on the same click. The input delay is 30 ms, processing takes 260 ms and painting the new grid takes 90 ms: 380 ms in total. FID never saw that interaction. INP reports roughly the slowest interaction on the page, so this visit’s INP is about 380 ms, in the “needs improvement” band. Across many visits, if the 75th percentile sits there, Search Console will flag the page group.

Does FID or INP affect SEO rankings?

FID has no effect on rankings any more, because Google’s systems no longer use it. INP is part of Core Web Vitals, which feed into page experience. Google’s own page experience documentation keeps this in proportion: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” In my audits, I treat Core Web Vitals as a tie-breaker between similarly useful pages and, more importantly, as a conversion issue. People abandon forms and baskets that freeze when they tap, whatever the rankings say.

So the practical order is: make the page the best answer first, then make sure INP, layout shift and loading are not working against it. My overview of all three Core Web Vitals shows how they fit together.

What to do now if you were tracking FID

1. Switch every report to INP

Search Console: the Core Web Vitals report now groups URLs by LCP, INP and CLS. Use it as your starting list of slow page templates.
PageSpeed Insights: the field data panel shows INP from the Chrome UX Report. My free PageSpeed and Core Web Vitals checker pulls the same data for a quick look.
Your own code: if you collect real-user data with the web-vitals library, upgrade and replace onFID with onINP. Use the attribution build so you get the slow element and the long script, not just a number.
Dashboards: remove FID charts from GA4 explorations, Looker Studio and monitoring tools so nobody makes decisions on a dead metric.

2. Use the right lab checks

Lighthouse never measured FID; it used Total Blocking Time (TBT) as a stand-in. TBT is still worth watching because long tasks hurt INP as well, but it only covers loading. For INP, open Chrome DevTools, record a Performance trace while you click the things real users click (menus, filters, add to basket, form fields), and look for long tasks and slow handlers attached to those clicks. Do it with CPU throttling on, because a budget Android phone is much slower than your laptop.

3. Fix the causes: most FID fixes still apply

Break up long tasks: split heavy JavaScript into smaller chunks and yield to the main thread between them, for example with scheduler.yield() where supported or setTimeout as a fallback.
Ship less JavaScript: remove unused code, defer non-critical scripts and split bundles by page. My guide to JavaScript SEO covers how this also affects crawling and rendering.
Audit third-party scripts: chat widgets, tag managers, ad and heatmap scripts are the most common cause of slow interactions I find. Remove the ones nobody uses and delay the rest.
Make handlers do the visible work first: update the screen, then send analytics or other background work afterwards.
Reduce rendering cost: keep the DOM small (see how rendering works), avoid layout thrashing in loops and use content-visibility on long off-screen sections.
On WordPress: heavy page builders and stacked plugins are the usual problem. My notes on Elementor technical fixes apply to most builders.

4. Re-check after 28 days

Field data in Search Console and PageSpeed Insights is a rolling 28-day window, so a fix takes up to four weeks to show fully. Use “Validate fix” in Search Console after you deploy.

If an audit, plugin or course still mentions FID

I still see FID in audit templates, WordPress speed plugins and agency reports, especially reports produced by older tools. Treat it as a warning sign about the report, not the site; a current technical SEO audit should report INP. Three questions to ask:

What date is the data from? FID values after September 2024 are not reliable, because Chrome no longer guarantees them.
Where is INP? A responsiveness section without INP is incomplete. Ask for it.
Is the recommended fix still sensible? Usually yes: reducing JavaScript and long tasks helps INP too. Keep the fix, drop the FID target.

Many Pakistani sites I review are browsed mostly on mid-range Android phones over mobile data, which is exactly where INP problems show up and FID used to hide them. If your Search Console mobile report shows poor INP and desktop looks fine, that is the pattern the Web Almanac numbers describe.

Check your understanding

What replaced First Input Delay as a Core Web Vital in March 2024?

Total Blocking Time (TBT)
Interaction to Next Paint (INP)
Time to Interactive (TTI)

INP became a Core Web Vital on 12 March 2024. TBT is a lab metric and TTI was removed from Lighthouse; neither is a Core Web Vital.

A page responds to the first tap in 40 ms but takes 450 ms to update after a filter is clicked. Which metric catches the problem?

FID only
Neither
INP

FID only saw the first interaction’s delay. INP looks at every interaction and reports close to the slowest one, so the 450 ms filter click is what counts.

What is the “good” INP threshold at the 75th percentile?

200 ms or less
100 ms or less
2.5 seconds or less

100 ms was the old FID threshold and 2.5 seconds is the LCP threshold. INP is good at 200 ms or less and poor above 500 ms.

Which of these is counted by INP?

Scrolling a long article
Pressing a key in a search box
Hovering over a menu

INP counts clicks, taps and key presses. Scrolling, zooming and hovering are not counted, just as they were not counted by FID.

Frequently asked questions

Is First Input Delay still a Core Web Vital?

No. Google replaced First Input Delay with Interaction to Next Paint on 12 March 2024. The current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.

What was a good FID score?

FID was rated good at 100 milliseconds or less at the 75th percentile, and poor above 300 milliseconds. That target no longer matters for SEO. The current equivalent is an INP of 200 milliseconds or less.

Can I still measure FID?

Not reliably. Chrome ended FID support on 9 September 2024, Google’s tools no longer report it, and version 5 of the web-vitals library removed onFID(). Measure INP instead.

Why did my site pass FID but fail INP?

FID only timed the wait before the first interaction’s handler started. INP times every interaction all the way to the next frame, so slow handlers, heavy re-rendering and sluggish later clicks that FID ignored now count.

Does INP affect Google rankings?

It is part of page experience, which Google’s core ranking systems take into account, but relevance comes first. Google says it shows the most relevant content even when page experience is sub-par. Good INP mainly protects conversions and can help between similarly useful pages.

What is the difference between INP and Total Blocking Time?

INP is a field metric based on real users’ interactions. Total Blocking Time is a Lighthouse lab metric for how long the main thread is blocked during loading. High TBT often predicts poor INP, so it is a useful early check, but it cannot replace field data.

Sources

HTTP Archive, “Web Almanac 2024: Performance” (2024).
web.dev (Google Chrome team), “Interaction to Next Paint (INP)” (2024).
web.dev (Google Chrome team), “Interaction to Next Paint becomes a Core Web Vital on March 12” (2024).
Google Search Central, “Understanding page experience in Google Search results” (accessed 2026).

If your Search Console report is flagging INP and you are not sure which script or template is responsible, my website speed optimisation service covers INP, LCP and CLS together, or you can ask me a question.