First Input Delay measures the millisecond gap between a user's first interaction (tap, click, key press) and the browser's actual response. It's a field metric collected from real users, not a lab test, and directly impacts perceived responsiveness during page load.
First Input Delay quantifies the time from when a user first interacts with a page—clicking a button, tapping a link, pressing a key—to the moment the browser can begin processing that event. It does not measure how long the event handler runs or how long the screen takes to repaint; it isolates the delay caused by the main thread being occupied. If a user clicks at millisecond 1200 and the browser starts handling the click at millisecond 1310, FID is 110ms.
This metric exists because JavaScript often blocks the main thread during initial page load. When a browser parses and executes large bundles, compiles code, or processes analytics tags, it cannot respond to user input simultaneously. FID exposes that blocking period from the user's perspective. The metric fires only once per page load—on the very first discrete interaction—and ignores scrolling or zooming because those are continuous gestures handled differently.
Google added FID to Core Web Vitals in May 2020 as the responsiveness signal, complementing Largest Contentful Paint for loading and Cumulative Layout Shift for stability. The goal was a field metric that reflected real interactivity frustration, not synthetic ideals. FID succeeded in surfacing main-thread bottlenecks but had a critical weakness: it only measured the delay before processing started, not the full interaction latency a user experiences.
A user who clicks a button and waits 600ms for the interface to update might see an FID of 80ms if the delay happened during event handling, not before it. This mismatch led Google to develop Interaction to Next Paint, which measures the entire lifecycle from input to visual feedback. INP became a Core Web Vital in March 2024, and FID was retired from the official set. Despite this, FID data persists in Chrome User Experience Report archives, PageSpeed Insights historical views, and many RUM platforms that have not yet fully migrated dashboards.
FID is a field metric, meaning it comes from real users in the wild through the browser's Performance Observer API. Chrome collects FID automatically and reports it to CrUX if the origin has sufficient traffic. Third-party Real User Monitoring tools like SpeedCurve, Sentry, or New Relic instrument pages with JavaScript snippets that listen for the first input event and calculate the delay using event timestamps.
You cannot measure FID in Lighthouse, WebPageTest, or any synthetic testing tool because those environments do not include a human clicking at an unpredictable moment. Lighthouse reports Total Blocking Time instead—a lab proxy that sums all main-thread tasks over 50ms during load. TBT correlates reasonably with FID but is not identical. If you want FID data before launching a page, you need to deploy to staging with analytics instrumentation and drive real traffic, or accept that TBT gives you directional insight only.
One frequent mistake is conflating FID with total interaction lag. A page can have excellent FID but terrible perceived responsiveness if event handlers themselves are slow or if the framework takes hundreds of milliseconds to re-render. FID ends the moment the browser begins processing; everything afterward is invisible to the metric.
Another confusion: assuming FID applies to all interactions. It measures only the first input on a page. Subsequent clicks, taps, or key presses are not included. This design choice was intentional—Google wanted a metric tied to the critical loading phase—but it means FID says nothing about responsiveness during scrolling, typing in a form, or interacting with a single-page app after initial render. That gap is precisely what INP addresses by sampling all interactions throughout the session and reporting the worst-case latency at the 75th percentile.
When FID exceeds 100ms, the culprit is almost always JavaScript monopolizing the main thread. Start by auditing your bundle size and loading strategy. Tools like Coverage in Chrome DevTools reveal how much code executes during load versus sits unused. Defer non-critical scripts with async or defer attributes, split vendor bundles so initial parse is lighter, and lazy-load below-the-fold components.
Third-party scripts—analytics, ads, chat widgets, social embeds—are common offenders. EachTag Manager container can inject dozens of requests that block parsing. Use Partytown or a web worker to offload third-party execution, or delay script injection until after the window load event. For first-party code, profile long tasks in the Performance panel. Look for functions that run longer than 50ms and either break them into smaller chunks with setTimeout or requestIdleCallback, or move expensive computation to a worker thread. Server-side rendering and static generation reduce client-side JavaScript load, directly lowering FID by giving the browser less work during the critical window when users are most likely to interact.
If you still track FID because your RUM platform or internal dashboards report it, understand that it no longer influences Core Web Vitals rankings as of March 2024. Google Search Console and CrUX API now surface INP data. The practical shift is minor for well-optimized sites—most techniques that reduce FID also improve INP—but the threshold and calculation differ.
INP measures every discrete interaction on the page, not just the first, and includes the full cycle to visual update. The good threshold is under 200ms, needs improvement from 200-500ms, and poor above 500ms. This means you cannot rely solely on optimizing initial load; you must ensure responsiveness persists during user sessions. Frameworks with heavy reconciliation (React, Vue, Angular) need particular attention to avoid slow re-renders triggered by state changes. Code-splitting, memoization, virtual scrolling, and debouncing user input all help. The monitoring infrastructure is similar—Performance Observer API, same RUM vendors—but you need to instrument for the new metric explicitly if your tool does not auto-detect it.
First Input Delay is a field metric measuring the actual delay a real user experiences before the browser begins processing their first interaction. Total Blocking Time is a lab metric that sums all main-thread tasks longer than 50ms during page load, providing a synthetic proxy. TBT can be measured in Lighthouse; FID cannot. TBT correlates with FID but is not identical because it does not depend on when a user chooses to interact.
Lighthouse runs in a controlled environment without user interaction, so it reports Total Blocking Time instead of FID. Real users interact at unpredictable moments—often mid-load when JavaScript is still parsing or executing. If your bundle is large or third-party scripts block the main thread, actual users will experience high FID even though TBT looks acceptable. Field data from CrUX or RUM tools reveals the gap.
FID no longer affects Core Web Vitals rankings as of March 2024, but it remains in historical CrUX data and many RUM platforms. If you are analyzing trends or comparing performance over time, you will encounter FID. The underlying optimization principles—reducing main-thread blocking JavaScript—apply equally to INP, so improving FID inherently helps the newer metric.
Yes. If the main thread is idle when a user interacts—meaning no JavaScript is parsing, compiling, or executing—the browser can process the input immediately and FID will be zero or near-zero. This is rare on modern pages with analytics, frameworks, and third-party tags, but static HTML with minimal scripting can achieve it consistently.
FID measures only the first interaction on a page load, so in a single-page app, FID fires once when the user first clicks after the initial route renders. Subsequent route transitions or interactions within the app do not generate new FID samples because they do not constitute a full page load. This is why INP is more relevant for SPAs—it captures responsiveness throughout the session, not just the initial moment.
Chrome User Experience Report provides FID data aggregated by origin if you have sufficient Chrome traffic. Real User Monitoring platforms like SpeedCurve, New Relic, Sentry, and Cloudflare RUM instrument your pages to collect FID from actual visitors. Google Analytics 4 can also report Web Vitals if you configure the measurement protocol. All require JavaScript instrumentation on the live site; synthetic testing tools cannot generate FID data.