First Input Delay explained

Google has long used page load time, the time it takes a page to fully load after someone tries to visit it, when deciding which pages to recommend to searchers. Load time, however, doesn’t tell the whole story.

Enter First Input Delay.

If you’ve read our previous coverage of Core Web Vitals, Google’s Page Experience update and Google’s prioritization of UX, you’ve seen that First Input Delay is one of the three metrics that make up the Core Web Vitals Google looks at when determining page experience.

In this guide (one of four that will delve into the details for CWV), we’ll cover everything you need to know to understand what First Input delay is, why it matters and how to optimize your website for FID.

What is First Input Delay?

First input delay, according to Google’s explanation, is "the time from when a user first interacts with a page to the time when the browser is actually able to begin processing event handlers in response to that interaction."

In other words:

First Input Delay is the amount it takes a page to respond to a user the first time they try to do something on the page.

In order to fully understand FID, let’s look at what happens when you try to interact with a page out on the web:

  1. Your browser makes a request to the website’s server to download all the necessary files in order to load and render the page.

  2. Your browser starts downloading and processing files in what’s called the "main thread".

  3. As the browser parses the page’s HTML code, it may start to render parts of the page. However, the browser will stop reading the HTML if it encounters any JavaScript.

  4. When it finds JavaScript, the main thread stops reading the HTML and instead downloads and runs the script.

  5. The browser won’t start parsing HTML until it finishes processing the JavaScript - so if the page code has two JS files in a row, the main thread will process both before it moves back to the HTML.

  6. Each time the browser encounters a script, it will load the script via the main thread. So the process of loading the page can (and often does) stop and start several times.

If a user tries to interact with the page while the main thread is busy processing a script, they’ll see a delay between when their action and the page responds. The time between when the user interacts with the page (clicks the button, for example) and the page reacts to the interaction is the "input delay".

An important thing to note here about FID: it only measures the time between the user’s interaction and when the server starts reacting. It doesn’t measure how long it actually takes the server to complete its task.

If a user clicks the play button on a video, FID refers to the amount of time it takes the website to start processing the command. It doesn’t measure the amount of time it actually takes the video to load, buffer or start playing.

The difference between FID and page speed

The difference between FID and page speed

At this point, you might be thinking that FID sure sounds a lot like other Google speed metrics like load time, time to first byte, first contentful paint and time to interactivity.

While true that each of those concepts measure some sort of amount of time, they are not the same thing as FID and therefore measure different aspects of a page’s usability.

Here’s how FID is different from other aspects of page speed:

  • Load time: Load time refers to the amount of time it takes a browser to fully load and render a page, regardless of any user actions. Short load times are important for usability, but it doesn’t measure how quickly a page responds to user engagement.

  • Time to first byte: Time for first byte measures how long it takes a server to start sending data when a browser requests a page. It tells you how fast a site’s server is and doesn’t tell you much about a page’s interactivity for users.

  • First contentful paint: First contentful paint is the amount of time between a page starting to load and the browser rendering the first bit of content on the page. First contentful paint measures the perceived load time for users because it tells us when people will first see something happening on their screen. However, it also doesn’t tell us much about what will happen when a user clicks a button when it loads.

  • Time to interactivity: TTI is a Performance metric in Google Lighthouse that tells you when a page becomes interactive as defined by Google. Like the other three metrics, though, it doesn’t tell you how long it takes a page to respond to interactions.

In a nutshell, the four metrics above all measure basically how quickly users can start using a page but they fall short of giving us a full picture of the page’s usability. First Input Delay fills this gap.

Why is First Input Delay Important?

As we’ve discussed, the key to successfully promoting your website online is providing an excellent experience for users. It should come as no surprise that one of the things that makes UX "excellent" is how much time people have to wait before a page starts working when they try to do something on it.

If your page is making users wait a long time before responding to their interactions, your brand is not impressing new users. Even your existing audience can get fed up with the wait and abandon you. In other words, FID is a way of quantifying if your website is making a good first impression or not.

From a more practical angle, a page’s First Input Delay score is a Core Web Vitals metric. And we know Core Web Vitals do impact a page’s ranking in search results.

Measuring and Tracking FID

In our previous guides on the individual CWV metrics, we discussed the concept of "field" vs. “lab” data:

  • Field data is collected from real users who visit a page out on the web. It’s collected and accessible through Chrome User Experience Reports. Field data will be slightly different for each user because they all have different devices and internet connections.

  • Lab data is measured through tests conducted in controlled environments, generally through software and other technologies, on predetermined devices and connections. There are no real users involved in lab data.

As it stands, First Input Delay is measured and scored based solely on real user data. It requires a real-life user to interact with your page, so is therefore a field-only metric.

As such, you need to track FID using field tools:

The FID score you want

First Input Delay is analyzed and scored on a spectrum:

  • An FID of less than 100 milliseconds is considered "good".

  • Delays between 100 and 300 milliseconds are scored as "needs improvement".

  • Any FID longer than 300 milliseconds is considered "poor".

First Input Delay scoring

Obviously, you want your users to wait as a short amount of time as possible after interacting with your page, but you should be aiming for less than 100 milliseconds for 75% or more of a page’s pageviews.

How to Get a Good FID Score

Break up Long Tasks

Anything that takes the main thread busy for 50 ms or longer is what’s known as a "long task". Since users who interact with a site while the main thread is busy have to wait for that task to end, it’s best to keep long tasks to a minimum.

Use Chrome DevTools to identify long tasks on your pages and then break them up into smaller, bite-sized tasks.

Async/Defer attributes

WooRank FID Async

JavaScript is an important part of the modern web, enabling all sorts of functionality for your website. It also just so happens to cause bottlenecks for a page’s main thread which leads to poor FID scores. The good news is that there are ways to tell browsers to skip individual scripts when loading the page: the Async attribute and the Defer attribute.

When a script’s HTML tag has the async attribute, it will be loaded in parallel to the main thread. This allows the page to continue loading and rendering while loading large or slow scripts at the same time.

The defer HTML attribute, as you might guess, instructs the user’s browser to wait (or "defer") for the rest of the page to load before downloading and processing the JavaScript.

These HTML attributes control the start and stop that occurs when browsers encounter JavaScript while parsing a page’s HTML. By removing a script from the main thread or waiting to process the script, you can speed up the HTML parsing and reduce input delay.

Use a Web Worker

Web workers are scripts created in a web page’s HTML code that run independently of the rest of the page. Web workers differ from scripts using the async or defer attributes in that, since they run in the background while the page loads, they aren’t impacted by scripts designed to execute after the user does something.

In other words, web workers can load JavaScript without blocking interactivity. So a page can load and execute a slow script without impacting FID.

Keep an eye on third-party scripts

Almost all websites rely on some sort of third-party code to add functionality or track data. Social sharing and analytics tools are two common third-party scripts you’re likely running on your website right now.

It’s good practice to keep an eye on when and how long they take to load. While you don’t control the code itself (and, therefore, can’t affect the size or speed), you can use methods like the async and defer attributes or web workers to prioritize tasks.

If a script doesn’t need to execute early in the loading process, consider deferring it or using a web worker to run it in the background.

Don’t Put Off Fixing Poor FID Scores

First Input Delay is one of the most important factors when it comes to evaluating the experience real-life users have when trying to interact with a page on the web. There’s a reason it’s a Core Web Vitals metric after all.

Its incorporation into Google’s ranking algorithm, along with the rest of the CWV metrics, further blurs the line between development, SEO and digital marketing and should serve as further proof that all three functions need to work in tandem from the very beginning of any project.