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
- Third-party code keeping the main thread busy for longer than expected
How can you 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.
deferattribute 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 adblocking? What you may not know is that adblocking has largely shifted to ad-filtering, with over 250M 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?