First Input Delay

Why It Matters

• Perceived responsiveness defines user experience. A page can look fully loaded but feel broken if clicking does nothing for two seconds. FID specifically measured this mismatch between visual readiness and actual interactivity.
• The main thread is the bottleneck. FID delays happen when the browser's main thread is busy with heavy JavaScript execution and cannot respond to user input. Long tasks — anything over 50 milliseconds — are the primary culprit.
• It only measured the first interaction. FID focused on the very first click or tap, which is why it was eventually replaced by INP, which tracks the responsiveness of all interactions throughout the page's lifecycle.
• The lessons still apply. Even though FID is no longer a Core Web Vital, the techniques for reducing input delay are the same ones that improve INP. Fixing the main-thread bottleneck improves all interaction responsiveness.

How to Reduce Input Delay

1. Break up long JavaScript tasks. Any JavaScript task that runs for more than 50 milliseconds blocks the main thread. Split long operations into smaller chunks using requestIdleCallback, setTimeout, or scheduler.yield() so the browser can respond to input between chunks.
2. Defer non-essential JavaScript. Scripts that do not need to run before the page becomes interactive should use defer or async attributes. Load analytics, ads, and non-critical features after the main content is interactive.
3. Reduce JavaScript bundle size. Less JavaScript means less parsing, compiling, and executing — which means the main thread is free sooner. Remove unused code, tree-shake dependencies, and code-split to load only what each page needs.
4. Move heavy work off the main thread. Use Web Workers for computationally intensive tasks like data processing, image manipulation, or complex calculations. This keeps the main thread available for user input.
5. Optimize third-party scripts. Analytics, chat widgets, ad scripts, and social media embeds often run heavy JavaScript during page load. Load them lazily or after the page becomes interactive.

Common Mistakes

• Loading everything eagerly. Including every script at the top of the page guarantees the main thread is saturated during the critical window when users first try to interact. Prioritize what loads first.
• Ignoring third-party impact. Developers often focus on their own code while third-party scripts silently block the main thread. Audit the total JavaScript executing during load — not just yours.
• Confusing FID with load time. A page can load quickly (fast FCP and LCP) but have terrible input delay if heavy JavaScript continues executing after visual content appears. Speed and responsiveness are different metrics.
• Not testing on real devices. Developer machines execute JavaScript much faster than average user devices. A 20ms task on your laptop could be a 200ms task on a budget phone. Test with realistic hardware.