First Input Delay (FID)

First Input Delay (FID) is a web performance and user experience metric that tracks the time from when a visitor first interacts with a web page to the time when the browser starts processing the interaction (only starts). Think of it as the lag between clicking a button and the browser actually beginning to respond to that click.

FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

It is measured in milliseconds. The time spent running the event handler does not count towards FID, so if your CPU is idle the First Input Delay will always be 0ms. FID only measures the "delay" in event processing.

Sites should strive to have a First Input Delay of 100 milliseconds or less.

Why FID happens?

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. One common reason this might happen is the browser is busy parsing and executing a large JavaScript file loaded by your app. While it's doing that, it can't run any event listeners because the JavaScript it's loading might tell it to do something else.

What if an interaction doesn't have an event listener?

FID measures the delta between when an input event is received and when the main thread is next idle. This means FID is measured even in cases where an event listener has not been registered.

INP vs FID

Unlike FID, INP also counts the time spent processing event handlers and repainting that result from user interaction. That means INP is always higher than FID. INP also looks at all user input, rather than just looking at the first interaction.

Causes of FID

The main cause of FID is heavy JS execution:

• Long-running JS tasks: Tasks that take longer than 50ms block the main thread and delay input processing.
• Heavy client side rendering logic: Hydration and other client-side rendering operations can monopolize the main thread.
• Long third-party scripts: External scripts from analytics, ads, or social media widgets can delay interactivity.
• Render blocking JS: JavaScript that must be parsed and executed before the page can be interactive.

Optimize FID

• Break up Long Tasks: FID should improve noticeably as you adopt best practices like code-splitting, lazy loading and breaking up your Long Tasks.
• Use a web worker: A blocked main thread is one of the main causes of input delay. Web workers make it possible to run JavaScript on a background thread. Moving non-UI operations to a separate worker thread can cut down main thread blocking time and consequently improve FID.
• Use async, defer for non-critical scripts: Prevent scripts from blocking the main thread during page load.
• Lazy load non-critical third-party JS: Defer loading of analytics and other non-essential scripts until after the page is interactive.
• Defer Hydration: Use techniques like progressive hydration to make the page interactive faster.