#Core Web Vitals

What is First Input Delay (FID), and how to improve it?

Sander van Surksum
by Sander van Surksum
iron-out-blog-first-input-delay-mirror-big-left

We have all been there: you’re on the world wide web, searching for a solution to a bugging problem. You are already a little on edge and quite impatient, when you open a webpage you found in the search engine results. While the page loads, you already know which button you want to click on. Even though you know, deep down, it is too early to click, you just can’t help yourself. You hear your laptop struggling, too many to-do’s at the same time (which, let’s be honest, we all feel like at times), and the screen freezes. You squint your eyes agitatedly at the logo of the webpage you were trying to open. “Damn you”, you hiss. Not a very good first impression.

Google has announced that FID will be replaced with Interaction to Next Paint (INP) as of March 2024. INP will provide a more comprehensive and accurate measure of input latency, thus enhancing our ability to understand and the page experience.

For more information, read our Interaction to Next Paint blog post where we'll delve deeper into the differences between FID and INP, and what this shift means for your website. We also got you covered on how to solve INP issues.

We’re talking about First Input Delay (FID) #

First Input Delay is a Google Core Web Vital metric used by Google’s Search Engine to rank your web page in the search results. Search engines want to give searchers exactly what they are looking for. The more a page seems to match the search query and provide a friendly user experience - the higher a page will rank in the Search Engine Results Page (SERP). The first impression your user has of a web page is essential. Do the pictures take too much time loading? Do the buttons respond sluggishly? Are there annoying pop-ups that are blocking exactly the piece of text that you want to read? Does the content provide you with a quick answer, just by scanning the page? If not, the searcher will bounce right off your page and back to the SERP, trying their luck elsewhere. And the more people bounce, the lower a search engine will rank your page.

Where the focus of search engines is mostly on relevance and authority, the speed and interactiveness (hence, Core Web Vitals core web vitals) are becoming increasingly important as benchmarks for user friendliness. The FID, First Input Delay, is one of those benchmarks. Unlike measuring how a user likes the design of a page, First Input Delay is easy to measure. It basically looks at the milliseconds your browser takes to respond to an interaction a user has with your site. As an interaction we do not count scrolling or zooming, but for example clicking that button that we mentioned earlier in this article. And to clarify: with ‘delay’, we really mean ‘delay’ only. So, the FID does not measure the time the browser takes to process the interaction or to load the interface afterwards. These are actions your browser will have to take anyway, delay or no delay.

What causes First Input Delay #

So, what causes this delay we are talking about? If that delay is not in the browser processing the interaction, nor in loading the interface afterwards, then where does this delay take place?

It might be good to understand how a browser loads, processes and responds to your search query demands in the first place. Let’s say you are looking to buy organic dog treats for your furry friend. You searched in Google, found a webpage that looked interesting and clicked on the link. Different resources are requested by the page. A header picture with a happy dog, appealing title, text block, menu with buttons and pop-up that invites you to leave your email address for free dog training tips. Once those resources are finished downloading, they're processed on the main thread on the page. So basically, the main thread is quite occupied with these tasks until the entire page is loaded. Apart from small time windows during the process, where the main thread is idle. In the image below you can see the process.

So let’s say you want to click a button in the menu that will take you straight to the sales page of the organic dog treats. The FID will measure the time from when a user clicks a button to the time when the browser responds to that click (i.e. when the browser starts navigating to that page). It’s like measuring the time from ringing someone’s doorbell to them answering the door. The timing of your click is critical. If you wait until the main thread is done with all the work loading and processing all the elements on the page, the amount of milliseconds it will take to respond will be considerably small. The same goes for any requests during the small breaks that the main thread takes. However, if you click on a button right when the main thread starts working on a task, your request is going to be put on hold until the main thread has cleared it’s schedule. The FID will increase and you will have to wait. We'd say: patience is a virtue, but why would we, if we can also just speed up the process?

Why measure the delay of the first interaction, and not the second or third? #

The answer to this question might be obvious, but let us break it down for you anyway (it’s why you’re here, is it not?) First and foremost, the responsiveness of the browser to the first action a user performs, is critical in shaping a first impression - and therefore inevitably also of the impression of the whole website or brand.

Next to this, the biggest delays - that need to be tackled - take place during the page load, when the main thread is busy running around, performing tasks and loading elements. During the page load is mostly when the first interactivity takes place. Recommendations on how to fix this delay and speed up the process, are not the same as solutions provided for slow responsiveness at other moments - say, when the page is loaded already. To be able to fix problems more specifically, it is important to separate out these metrics.

Measuring in the field vs. measuring in the lab #

There are two different ways to measure website performance: in the field and in the lab. With ‘the field’ we mean real life users, people on the world wide web who interact with your site. In the lab, we can only look at existing data and settings. We think it goes without saying that the Core Web Vitals, including FID, can only be measured in the field, as it relies solely on user interaction.

For testing within the lab, Google currently uses a preset of six different metrics in their Lighthouse Performance scoring. Since they don’t have actual input from a user, they replace FID with Total Blocking Time (TBT) since both strongly correlate. Instead of looking at the delay it looks at the time the main threat was blocked because that can be simulated.
We don’t go into detail about TBT in this blog but know that if you don’t have enough visitors to measure FID in the field but you see that you have issues with your TBT, you might focus on improving this metric since you most likely will improve FID too.

Curious how we can improve your performance?

Check the performance of your website using the Core Web Vitals and Lighthouse performance reports.

What is a good FID score? #

So, all fine and dandy, but let’s move on to why you are really here. You want to know how your site is performing, and what you can do to improve core web vitals such as the FID. To provide a user experience that satisfies both user and search engine, your site should strive to have a First Input Delay of 100 milliseconds or less. To ensure you're hitting this target for most of your users, Google uses the 75th percentile of page loads, segmented across mobile and desktop devices.

  • Good: <= 100ms
  • Needs improvement: > 100ms and <= 300ms
  • Poor: > 300ms

Tools to measure First Input Delay #

Google and digital experts provide tools to help business owners gain a better understanding of FID.

The first two are considered to provide field data of a site based on real user interactions:

The next two provide users with scores from lab data:

How to improve FID #

  • When it comes to optimizing FID, you can focus on the following major improvement areas:
  • Improve your CSS and code by minifying and compressing it.
  • Optimizing your JavaScript (JS) code by:
    • Breaking it up in smaller asynchronous tasks.
    • Generating as much as you can statically, server side (like our Iron/Out website).
    • Investigating your third-party scripts. Is it really needed that everything loads right away or on every page?
    • Using web workers to delegate some of your JS code to relieve your main thread.
    • Minimizing unused polyfills for older browsers.
  • Consider idle until urgent coding strategy.

Conclusion #

First impressions come only once in life. So you’ve got one single shot to aim right and hit the bull’s eye. Better make it count! For websites, speedy interactions are key in these crucial first encounters. An optimised First Input Delay is your friend: better keep ‘em close and push that score down to below the 100ms.

Now that we’ve come to the end of this article, you might know more about search engine preferences, main threads and organic dog treats. You’ve learned how a browser loads your page and got to know tools to help you improve your FID. If you still struggle on how to start using this metric to improve your site’s ranking (no worries, you’re only human), don’t hesitate to contact us for guidelines or advice!

Continue reading

Get more business out of your website

The performance of your website needs improvement.

You can get more business by creating happy customers by giving them a good user experience. Start now and request a performance audit.