First Input Delay (FID)

TL;DR — First Input Delay (FID) is an old metric. It measured how long your page made someone wait before it could even start reacting to their first click or tap. Google retired it in March 2024 and replaced it with INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., then removed it from its tools entirely in September 2024. So there’s nothing to fix here anymore — but it’s worth knowing what it was if you run into “FID” in old reports.

What First Input Delay was

When you tap a button and nothing happens for a beat, the page feels broken — even if it looks loaded. First Input Delay (FID) was Google’s way of putting a number on that specific frustration.

FID measured one narrow thing: the gap between your first interaction with a page (a click, a tap, a key press) and the moment the browser was actually free to start responding to it. If the browser was busy running JavaScript when you tapped, your tap had to wait in line. That wait was the “delay.”

Two things it did not measure:

• How long the button’s code took to run once it started.
• How long the page took to visually update afterward.

Just the wait before anything could begin. That narrowness is a big reason it eventually got replaced.

What counted as a good score

FID was scored in milliseconds:

• Good: 100 ms or less
• Needs improvement: 100–300 ms
• Poor: over 300 ms

Why you don’t need to worry about it anymore

Here’s the important part for anyone reading this in 2026: FID is retired. Google replaced it as a Core Web Vital with INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (Interaction to Next Paint) on March 12, 2024 — Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. stopped showing FID that same day. PageSpeed Insights and the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API kept reporting it a little longer, then dropped it on September 9, 2024. If a tutorial or an old dashboard still lists FID as a current Core Web Vital, that content is out of date.

INP does the same job better: instead of only timing the first interaction’s wait, it measures the full responsiveness of every interaction throughout a visit. If you’re trying to make your site feel snappy today, INP is the metric to watch, not FID.

Want the full history — the exact thresholds, why FID was designed so narrowly, where old FID data still lives, and how it maps onto INP — switch to the Advanced tab.

TL;DR — FID was the Core Web Vital for responsiveness until INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. replaced it on March 12, 2024 — the date Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. also dropped it from its report. Chrome tools, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., and the live CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API kept it a little longer and cut it on September 9, 2024, each on its own schedule. It measured only the input delay of the first interaction — not handler runtime, not repaint — deliberately, to avoid perverse incentives. Thresholds: good ≤100 ms, poor >300 ms at p75, field only (Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. was the lab proxy — a correlated diagnostic, not a conversion formula). Don’t confuse those thresholds with INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.’s 200/500 ms, and don’t try to convert one metric’s number into the other. Poor FID came from main-thread contention — long JavaScript tasks — which is exactly what causes poor INP and TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital., so the legacy fixes still pay off. Historical FID data survives in the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. BigQuery dataset (through the 202409 release); it’s gone everywhere live.

What FID actually measured

Google’s definition was precise. Per web.dev: “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.”

Read that carefully, because the scope is the whole story. FID captured the delay before processing could begin — and nothing after. Not how long the event handler ran. Not how long the page took to paint the result. Just the wait.

Why was the browser ever “not able to begin”? web.dev is blunt about the cause: “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” There is one main thread, and if it’s mid-task parsing or executing JavaScript when the user acts, the interaction sits in the queue until that task finishes. I make the same point in my Ahrefs FID guide: there’s just one main thread, JavaScript competes to run tasks on it, and while a task is running the page can’t respond to input — that stall is the delay a user actually feels.

Why FID only measured the delay (not the whole interaction)

This looks like a design flaw until you understand the reasoning. Google measured only input delay on purpose. Folding the handler’s execution time and the repaint into the metric could, as web.dev explains, incentivize developers to game it — they could wrap their event-handler logic in an asynchronous callback to split it off from the interaction’s task and make the number look better while the actual experience got worse. So FID stayed narrow.

That narrowness is also FID’s fatal limitation. A page could post a great FID and still feel sluggish, because every interaction after the first went unmeasured, and the slow part of an interaction is often the processing and repaint FID ignored. That gap is precisely what INP was built to close.

The thresholds — and the one you’ll see people get wrong

Measured at the 75th percentile of page loads, segmented across mobile and desktop. web.dev’s guidance was simply that sites should strive for a First Input Delay of 100 milliseconds or less. My own FID article uses the same figures — good ≤100 ms, needs improvement >100 ms and ≤300 ms, poor >300 ms.

The common mistake: confusing FID’s thresholds with INP’s. They are different numbers for different metrics. FID = 100 ms good / 300 ms poor. INP = 200 ms good / 500 ms poor. Several third-party summaries — and even automated content passes — conflate the two, so if you see “200 ms” cited as FID’s good threshold, it’s wrong.

FID was a field-only metric

You could never get FID from LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or any lab tool, because it required a real user’s real first interaction — web.dev states plainly that FID is a metric that can only be measured in the field, as it requires a real user to interact with your page. Lab tools don’t click, so there was nothing for FID to time.

The lab stand-in was always Total Blocking Time (TBT). As I put it in my PageSpeed Insights guide, you won’t find FID or INP in lab data — those require clicks on the page that lab testing doesn’t reproduce — so you use Total Blocking Time as a proxy metric to work on improving instead. That relationship outlived FID: TBT is now the lab proxy for INP.

One guard worth stating plainly: TBT is a correlated diagnostic, not a conversion formula. There was never an equation that turned a TBT number into an exact FID number, and there isn’t one for INP either — a bad TBT score tells you main-thread work is a likely culprit, not what your field FID or INP would have been.

Why FID was retired: the INP transition

FID’s replacement was announced well in advance. Per web.dev, INP officially became a Core Web Vital and replaced FID on March 12, 2024, at which point FID was deprecated and removed from the program. Google’s stated reasoning: over time it became clear a new metric was needed to capture aspects of interactivity that FID did not.

The timeline had two distinct milestones — worth keeping straight, because it’s easy (and common, even in automated content) to collapse them into a single date:

1. March 12, 2024 — retired as a Core Web Vital. INP took over; FID was no longer part of the ranking-relevant Core set. Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. removed FID from its Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. that same day.
2. September 9, 2024 — removed from the tools, on product-specific schedules. Per web.dev, as of that date FID was no longer supported in Chrome tools. PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. stopped displaying real-user FID data and the CrUX API discontinued serving the metric going forward; the CrUX BigQuery dataset stopped adding new FID fields starting with the 202409 release, though earlier months stayed queryable.

It’s not accurate to say every Google surface dropped FID on September 9 — Search Console’s cutoff was six months earlier, tied to the INP replacement, not the later tools cleanup.

web.dev’s own FID article now leads with the retirement notice: First Input Delay is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric. And Google Search Central’s current Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. documentation doesn’t mention FID at all — it covers only LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INP, and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. When the official ranking doc stops naming a metric, that’s about as retired as it gets.

FID vs INP: what changed

The two metrics measure genuinely different things, which is why you can’t just map one onto the other:

The through-line: FID timed the front door of one interaction; INP times the whole journey of every interaction. There’s no formula that converts an old FID number into an equivalent INP number, and a page’s FID relative to other pages doesn’t predict its INP ranking relative to those same pages — they’re measuring different interaction sets against different endpoints, so any resemblance between the two numbers on a given page is coincidental, not a rule. See Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. for the full treatment of the metric that replaced it.

Where old FID data still lives

Retirement didn’t vaporize the historical record. What’s gone versus what remains:

• Gone (live/current-facing): Search Console’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. dropped FID on March 12, 2024, the day INP took over. The PageSpeed Insights UI and the live CrUX API kept reporting it a little longer and stopped on September 9, 2024.
• Still there (historical): FID data from before the cutoff remains queryable in the public CrUX BigQuery dataset — but only through the 202409 dataset; BigQuery stopped adding new FID fields starting with that release, though earlier months stayed in place. If you need to reconstruct a site’s old responsiveness history, that’s where to look — not the live tools. Pin the dataset month when you cite a number, label it historical, and don’t treat a legacy FID figure as numerically comparable to a current INP figure — there’s no conversion between them (see the comparison table above).

Does FID still matter today?

Directly, no — there’s nothing left to measure or report, so there’s nothing to “fix.” But the causes of poor FID and the causes of poor INP are nearly identical: long JavaScript tasks hogging the main thread. So any work you already did to improve FID wasn’t wasted. As I note in my FID guide, even though FID was replaced by INP in March 2024, it’s still worth working on the same underlying issues — many of the things you do to improve TBT and FID also improve INP.

The fixes that reduced FID are the same ones that help INP and TBT now:

• Reduce the amount of JavaScript you ship.
• Load JavaScript later where you can (async/defer).
• Break up long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. with code splitting so no single task monopolizes the main thread.
• Move work off the main thread with web workers.
• Use server-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. or prerendering to cut client-side work.

Was FID ever a big ranking factor?

Even while active, FID — as part of Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. — was never a heavy ranking signal. Google representatives have repeatedly characterized Core Web Vitals as closer to a tiebreaker than a primary signal, applied only when other things are roughly equal. My own read, from my Core Web Vitals guide, is the same: “I don’t think Core Web Vitals have much impact on SEO and, unless you are extremely slow, I generally won’t prioritize fixing them.” FID rarely got singled out on its own in rep commentary — it was almost always discussed as part of the Core Web Vitals bundle, not as a standalone ranking lever.

Bing and FID

There’s effectively no Bing-specific angle here. Bing never adopted Core Web Vitals as a named ranking signal the way Google did, and it never published FID (or INP) thresholds of its own. Bing cares about fast, responsive pages in general terms, but FID was a Google-ecosystem metric from start to finish.

TIP Measure INP now instead of optimizing a retired FID score

FID measured only the first input delay. This current field result uses INP and shows the full interaction-latency metric that replaced it.

Check current Core Web Vitals with my free Page Speed Test Free

1. Test the live URL and confirm the result uses field INP rather than historical FID.
2. Prioritize long main-thread tasks and interaction latency when INP is the failing metric.
3. Rerun after the trailing field window updates; use lab work only to diagnose candidate causes.

Tap to enlarge

The mobile field result reports LCP 2.2 seconds, INP 680 milliseconds, and CLS 0.07. It marks the page as failing Core Web Vitals and recommends reducing interaction latency by breaking up long main-thread tasks and deferring nonessential work.

Where to go next

FID sits under the Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. initiative, in the Web Performance cluster. The metrics most relevant to FID:

• Interaction to Next Paint — the Core Web Vital that replaced it, and the one to actually optimize for now.
• Total Blocking Time — the lab proxy that stood in for FID (and now stands in for INP) whenever you couldn’t measure real interactions.
• Core Web Vitals — the ranking-relevant trio (LCP, INP, CLS) FID used to belong to.

AI summary

A condensed take on the Advanced version:

• FID = a retired Core Web Vital for responsiveness. It measured only the input delay of the first interaction — the wait before the browser could begin processing the event handler — not the handler’s runtime or the repaint.
• Thresholds: good ≤ 100 ms, needs improvement 100–300 ms, poor > 300 ms, at the 75th percentile, mobile/desktop split. Field only — never measurable in LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.; Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. was the lab proxy.
• Don’t confuse thresholds: FID = 100/300 ms; INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. = 200/500 ms. Different metrics, different numbers.
• Cause of poor FID: main-thread contention — long JavaScript tasks. Same root cause as poor INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. and TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital..
• Retirement timeline: replaced by INP on March 12, 2024 — the same day Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. dropped FID from its report. Chrome tools, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., and the live CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API stopped supporting it on September 9, 2024, each on its own schedule — not a single universal cutoff. Google Search Central’s current CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. doc no longer mentions it.
• FID vs INP: FID timed the first interaction’s delay; INP measures all interactions’ full latency (delay + processing + presentation). No formula converts one metric’s number into the other.
• Old data: gone from the live tools; pre-cutoff FID data still lives in the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. BigQuery dataset through the 202409 release — pin the dataset month and don’t compare it numerically to current INP.
• No conversion, ever: TBT is a correlated lab proxy for FID and INP, not a formula that translates one into the other.
• Still matter? Nothing to fix directly, but the JS fixes (reduce/defer JS, break up long tasksAny main-thread task over 50 ms — the primary cause of INP regressions., web workers, SSR) carry straight over to INP and TBT.
• Ranking weight: minor even when active — CWV framed as a tiebreaker; Patrick: don’t prioritize unless you’re extremely slow. Bing has no FID equivalent.

Official documentation

Primary-source documentation on FID and its retirement.

Google / web.dev

• First Input Delay (FID) — the metric’s definition, thresholds, why only input delay was measured, and the retirement notice (Philip Walton; updated 2024-10-06).
• Chrome ends support for First Input Delay — the September 2024 removal from Chrome tools, PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., and the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API (Rick Viscomi).
• Interaction to Next Paint becomes a Core Web Vital on March 12 — the announcement that INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. would replace FID (Jeremy Wagner, Rick Viscomi).
• Understanding Core Web Vitals and Google Search results — the current ranking doc, which now lists only LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (no FID).
• Interaction to Next Paint (INP) — the metric that replaced FID.

MDN

• First Input Delay (FID) glossary — a short reference definition.

Bing / Microsoft

• None specific to FID. Bing never published FID thresholds or named Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. as a ranking signal of its own.

Quotes from the source

On-the-record statements from Google’s official web.dev documentation. Each link is a deep link that jumps to the quoted passage on the source page.

Google / web.dev — what FID measured

• “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” Jump to quote
• “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” Jump to quote

Google / web.dev — the “good” threshold

• “To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.” Jump to quote

First Input Delay cheat sheet

Status: retired. Keep this for reading legacy data and old reports — not as an optimization target.

FID at a glance

FID vs INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. — don’t mix them up

Key dates

• March 12, 2024 — INP replaces FID as a Core Web Vital; Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. drops FID from its report the same day.
• September 9, 2024 — Chrome tools, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., and the live CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API stop supporting FID, on their own schedule (not the same date as GSC).

Where FID data is now

• Live tools (PSI UI, GSC, CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API): gone (GSC since March 12, 2024; PSI/CrUX since September 9, 2024).
• Pre-cutoff history: CrUX BigQuery dataset, through the 202409 release. Don’t compare its numbers directly to current INP — there’s no conversion.

Fixing the underlying issue (helps INP/TBT now)

• Reduce JavaScript · defer/async load · break up long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. (code-split) · web workers · SSR/prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..

Mistakes to avoid with legacy FID data

Treating FID as a current Core Web Vital

FID was replaced by INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. in March 2024 and removed from current Chrome reporting surfaces later that year. Use INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. for current responsiveness work; keep FID only when interpreting historical datasets.

Comparing FID and INP against the same thresholds

FID’s historical Good/Poor thresholds were 100/300 ms; INP’s are 200/500 ms. The numbers are not interchangeable because FID measured only pre-handler delay, while INP covers the interaction through the next paint.

Looking for FID in a lab test

FID required a real first user input and was field-only. Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. was the lab proxy; a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. result was never a direct FID observation.

Optimizing a retired score instead of the user problem

Do not preserve a FID dashboard as the goal. Break up long main-thread tasks and reduce blocking JavaScript, then measure current responsiveness with INP in the field.

Test yourself: First Input Delay (FID)

Five quick questions on what FID measured and why it’s retired. Pick an answer for each, then check.

First Input Delay (FID)

First Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.

Related: INP, Core Web Vitals, TBT

First Input Delay (FID)

First Input Delay (FID) was the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. metric for responsiveness before Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) took its place. It measured only the input delay — the time from a user’s first interaction with a page (a click, tap, or keypress) to the moment the browser’s main thread was free to begin running that interaction’s event handlers. It did not measure how long the handler took to run, or how long it took the page to visually update afterward.

FID’s official thresholds were ≤ 100 ms good, 100–300 ms “needs improvement,” and > 300 ms poor, measured at the 75th percentile and segmented across mobile and desktop. Because it required a real user’s first interaction, FID could only be measured in the field — never in lab tools like LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., which used Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.) as the proxy instead.

FID was retired as a Core Web Vital on March 12, 2024, replaced by INP — Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. dropped FID from its report that same day. Chrome’s tools, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., and the live CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API kept reporting it a little longer and stopped on September 9, 2024. Historical FID data from before that cutoff is still queryable in the public CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. BigQuery dataset, through the 202409 release — don’t compare those legacy figures numerically to current INP data; there’s no conversion between the two metrics. Treat FID as a legacy/reference metric — the JavaScript fixes that improved it (breaking up long main-thread tasks) are the same ones that improve INP today.

Related: INP, Core Web Vitals, TBT

Changelog