Understanding and improving First Input Delay (FID)

A lot of things need to come together for a site to truly delight its users. The site needs to load relatively fast, the content shouldn’t shift around too much, and the page must be interactive.

The last bit is especially important because even if the page loads fast and content doesn’t shift abruptly, everything falls apart if the webpage fails to respond to the user’s initial interaction request. First impressions are important, and a site that responds to user requests in a timely manner during their first interaction is often perceived as usable and reliable.

In this last guide in our Core Web Vitals explainer series, we’ll be reviewing a UX metric called First Input Delay (or FID), which is used to measure a site’s responsiveness to user inputs. We’ll also talk about what a good FID score looks like and how to improve it.

What is First Input Delay?

The First Input Delay metric measures the time between (in milliseconds) the first user interaction with your site (i.e., when a user clicks on a link, taps a button, or uses a custom, JS-powered control) to the time that the browser is actually able to respond to that interaction.

Scrolling and zooming are not counted when measuring FID, as no response is expected from the website for those actions. The goal of FID is to determine the responsiveness of the site while it’s loading, so that users are reassured that the site is usable.

How is First Input Delay measured?

FID only measures the “delay” in event processing. It does not measure the event processing time itself or the time it takes the browser to update the user interface after running the event handlers. This is done deliberately to avoid incentivizing developers to respond to events asynchronously, which might improve the metric but likely make the experience worse for users.

One question that arises is that delay can occur during the entire lifecycle of content consumption, so why focus specifically on first input delay? Here are a few reasons:

  • The biggest interaction delays on sites typically occur during the initial page load. This is why Google believes that focussing on improving the user’s first interaction with a site will result in the greatest impact on improving the overall interactivity on the Web.
  • First input delay measures the user’s first interaction experience with your site. Initial impressions can go a long way in determining how the majority of users perceive the overall quality and reliability of your site, and whether the users stay or leave.
  • The solutions recommended for optimizing FID are not necessarily the same that you would implement to improve interactivity after the page load is complete. By clearly demarcating the two types of input delays, developers can better optimize for them.

What is a good FID score?

Since FID measures the delay in the user’s first interaction time with the website, a lower score (in terms of time) translates to a better user experience.

  • Good: Under 100 ms
  • Needs improvement: Between 100-300 ms
  • Poor: More than 300 ms

Factors that contribute to a poor FID score

In general, input delay happens because the browser’s main thread is busy doing something else, so it cannot (yet) respond to the user. Here are some factors:

  • Images and scripts being downloaded in a disorderly manner
  • Browser is busy parsing and executing a large JavaScript file
  • Third-party code keeping the main thread busy for longer than expected

How can you improve your FID score?

  • Break up Long Tasks: Long taks are JavaScript execution periods that block the thread for at least 50 ms. Long Tasks are indicative of JavaScript bloat, i.e., loading and executing more JS than the user may need right now. Breaking up Long Tasks using code-splitting into smaller, asynchronous tasks should help improve your FID score.
  • Review third-party code: Third-party tags and analytics code can periodically keep the main thread busy, rendering the page unresponsive to user input. Third-party code can also take precedence over first-party code. Developers should consider on-demand loading of third-party code and prioritize the loading based on what users are likely to value most.
  • Use a Web Worker: Since a blocked main thread is the primary reason for high FID score, moving non-UI operations to a background thread can help improve performance. This is what Web Worker libraries such as Comlink, Workway, and Workerize essentially allow you to do. Here’s a guide on using Web Workers to execute JS off the main thread.
  • Reduce JS execution time: Reducing the amount of JavaScript on the page also means reducing the amount of time that the browser will spend executing said code. One part of this is conducting a periodic audit of all the code being loaded and removing any unused JavaScript code. All JavaScript code is render-blocking by default, so consider using the defer attribute to reduce the input delay contributed by non-critical JS.

While you're here...

Did you know that the average publisher loses 10-40% of their revenue to ad blocking? What you may not know is that ad blocking has largely shifted to ad-filtering, with over 300M users allowing a safer, less interruptive ad experience to be served to them—in turn supporting their favorite sites and creators.

Blockthrough's award-winning technology plugs into publishers' header bidding wrapper and ad server to scan ad creatives for compliance with the Acceptable Ads Standard to activate this "hidden" audience and generate incremental revenue, while respecting the choice and experience of ad-filtering users.

Want to learn more?