First Input Delay (FID): Definition, Replaced by INP

What is First Input Delay (FID)?

First Input Delay (FID) was a Core Web Vital that measured the time from when a user first interacts with a page (e.g., clicks a link, taps a button, presses a key) to when the browser is actually able to respond. It captured the "feels frozen" experience users get when JavaScript is busy executing and the page can't react to input.

Important: FID was officially replaced by Interaction to Next Paint (INP) as a Core Web Vital on March 12, 2024. FID is now deprecated. New audits should use INP. This page covers FID for historical context — for current optimization, focus on INP.

What FID measured

FID was the time between a user's first input and the browser's main thread becoming free to process it. It only measured the first interaction (any subsequent input was ignored). It was a "field-only" metric — synthetic tools (Lighthouse) reported Total Blocking Time (TBT) instead.

Why FID was replaced by INP

FID had limitations that prompted Google to develop a successor:

• Only first interaction. Slow interactions later in the session were invisible. A page could pass FID but feel sluggish throughout.
• Only delay, not full response. FID measured input → start of processing. It missed the time taken by event handlers + rendering.
• Many users had ~0ms FID. If they didn't interact early, FID didn't capture them at all.

INP fixes these: it samples interactions throughout the page lifecycle, reports the worst (or near-worst), and measures end-to-end (input → next paint).

FID vs INP comparison

How FID was measured

// Browser Performance API
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const fid = entry.processingStart - entry.startTime;
    console.log('FID:', fid);
  }
}).observe({ type: 'first-input', buffered: true });

The first-input entry was reported on the first eligible interaction (click, tap, keypress).

Common FID causes (still apply to INP)

• Long-running JavaScript. Main thread busy for > 50ms blocks input.
• Large bundles loading. JS parse/compile blocks the thread.
• Third-party scripts. Ads, analytics, chat widgets.
• Heavy hydration. SSR/SSG sites "hydrating" on load.
• Long event handlers. Callback runs synchronously for too long.
• Layout thrashing in handlers. Reading + writing DOM in a loop.

Improving FID/INP: practical steps

1. Code splitting

// Don't ship everything at once
import('./heavy-feature').then(mod => mod.init());

2. Defer non-critical JavaScript

<script src="analytics.js" defer></script>
<script src="chat-widget.js" async></script>

3. Break up long tasks

// Bad: one long task
for (const item of bigArray) heavy(item);

// Good: yield to main thread between batches
async function processInBatches(arr) {
  for (let i = 0; i < arr.length; i += 100) {
    arr.slice(i, i + 100).forEach(heavy);
    await new Promise(r => setTimeout(r, 0)); // yield
  }
}

4. Use requestIdleCallback for low-priority work

requestIdleCallback(() => {
  prefetchNextPage();
});

5. Reduce third-party impact

• Load via <link rel="preconnect"> for known domains
• Self-host critical fonts/scripts
• Audit + cull unused tags (Tag Manager bloat is common)

6. Optimize hydration

• Partial hydration (Astro Islands)
• Server Components (React)
• Resumability (Qwik)

Lab equivalent: Total Blocking Time (TBT)

FID/INP are field-only metrics (need real users). For lab/CI testing, use Total Blocking Time (TBT) — sum of all main-thread blocking time during page load. Strong correlation with FID/INP.

FAQ: First Input Delay

Is FID still a Core Web Vital?

No. As of March 12, 2024, INP (Interaction to Next Paint) replaced FID as a Core Web Vital. FID is deprecated.

Should I still optimize for FID?

The same optimizations help both. Optimizing for INP automatically improves what was being measured by FID.

How does FID differ from TBT?

FID = field metric (real users, first interaction only). TBT = lab metric (synthetic, sum of blocking time). They correlate but are not the same.

Why did Google replace FID with INP?

FID only measured first interaction. INP samples interactions throughout the page lifecycle and measures end-to-end (input → next paint), giving a more accurate picture of real responsiveness.

Does my old FID-optimized code automatically pass INP?

Mostly yes — the underlying causes (long tasks, blocking JS) are the same. But INP is stricter (covers more interactions), so previously-passing pages may now fail.

Where can I see FID data?

Historical CrUX data still includes FID, but new dashboards default to INP. Use BigQuery for historical FID analysis if needed.

What's the difference between FID and Time to Interactive (TTI)?

FID: actual delay on first user input. TTI: when the page is "reliably interactive" per a heuristic. TTI is lab-only and has been criticized as unreliable.

Test responsiveness under load with LoadFocus

LoadFocus runs Lighthouse audits from 25+ regions and tracks INP/TBT scores over time, helping you ship pages that pass Core Web Vitals. Sign up free at loadfocus.com/signup.