Core Web Vitals: 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:
Your browser makes a request to the website’s server to download all the necessary files in order to load and render the page.
Your browser starts downloading and processing files in what’s called the "main thread".
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
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".
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.
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.
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
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.
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
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.