Core Web Vitals: First Input Delay (FID)

First Input Delay, or FID, is a metric being used in Google’s May 2021 page experience ranking update. It is one of three Core Web Vitals included in the update, all of which you can learn more about in our previous post. We’re covering these metrics individually to help you make sure your site is prepared.

What is First Input Delay?

FID is the time delay or latency between a user’s first discrete action and when the browser starts processing the response to that interaction. In simple terms, it is the time it takes for your website to start processing user input. To fully understand, we need to break down what this means.

The time delay or latency occurs when a browser is busy doing something else, be it loading assets or running JavaScript, so it can’t yet process the user’s input.

A discrete action refers to actions like clicks, taps, and key presses. Other actions, like scrolling and zooming, are known as continuous actions and run differently in most browsers.

The browser starts processing the response as soon as it is able, but the first input from the user may happen while your website is still loading or processing information.

Often, the first input occurs between First Contentful Paint (FCP) and Time to Interactive (TTI). This can mean that the browser’s main thread is busy requesting resources, or executing JavaScript. Even if the first input happens when the main thread is idle, you want to make sure your website is optimized to respond quickly.

Why is FID important?

As connections and devices have gotten faster, our patience and attention as users has gotten shorter. Giving users immediate feedback to their interactions is key to keeping them engaged. Most interactivity issues occur during page load. By eliminating any issues upfront, you will see greater impact and improvement to your website overall. This is the user’s first impression of your website, so you want to make sure it reflects the quality and reliability of your business.

How is FID measured?

FID focuses on the responsiveness in the RAIL performance model and looks at the time it takes for the browser to start processing the user’s action on its main thread. It does not measure the event processing time itself, or UI changes in the browser. While these are important to the overall user experience, they are not counted in this metric.

It is important to note that not all users will interact with your website at the same time or in the same way. Some users may interact with your website while the browser is busy, and others might not interact with a direct action at all. This means that FID requires real field data to report this metric.

To get the scoring metrics for all these factors, there are some tools that can be used.

Field tools

How to improve FID

As mentioned above, most user interactions will happen between First Contentful Paint (FCP) and Time to Interactive (TTI). This is when the page starts displaying and when it finishes. It is also the time the browser will be the busiest loading. Optimizing and reducing the time it takes for your website to load will help greatly.

There is also the Total Blocking Time (TBT). This is the amount of time between FCP and TTI where the main thread prevented an input from responding because it was too busy. Unlike FID, this metric can be lab tested and correlates with the FID. Improving TBT in the lab should also improve FID for your website. For a more in-depth look into improving the FID score, Google has released an Optimize FID article on the web.dev site.

In the next post, we will be continuing on our Core Web Vital quest, taking a deeper look at Cumulative Layout Shift (CLS).

Read the rest of our series to learn more about Google’s Core Web Vitals:

See how Hall can help increase your demand.