First Input Delay
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, 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 of time it takes a page to respond to a user the first time they try to do something on the page.
It’s sort of like when you receive a call on your phone. When you hear your phone start to ring you might answer it right away or maybe you have your hands full or you’re in the middle of doing something.
The time between when your phone starts ringing and when you actually move to answer it is the input delay.
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”.
- As the browser reads the page’s HTML code, it may start to render parts of the page.
- When the browser finds JavaScript files, the main thread stops reading the HTML and focuses on the JavaScript.
- The browser won’t go back to the HTML code until it finishes processing the JavaScript - so if the code has two scripts in a row, the main thread will process both before it moves back to the HTML.
Each time the browser encounters a JavaScript file, it’ll repeat steps 3-5. So loading a webpage can (and often does) stop and start several times.
When a user tries to interact with an element on the page while the main thread is busy dealing with a script, there’ll be a delay between their action and the page’s response. The time between when the user interacts with the page (clicks the button, for example) and when 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.
So when 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.
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 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 tell us how long it takes a page to start sending information, start displaying content, finish loading or become fully usable. But they don’t tell us how long a page takes to start becoming usable.
First Input Delay fills this gap.
Does First Input Delay Matter?
As we’ve discussed, the key to successfully promoting your website online is providing an excellent experience for people. One of the things that makes UX “excellent” is minimizing how much time people have to wait for a page to start working when they try to interact with it.
If your page makes users wait a long time, 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 quantifies how good a first impression a website is making with you audience.
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.
Fixing a Poor First Input Delay Score
What causes input delays?
FID happens when the user tries to get a website to do something, but their browser is busy doing something else. The website’s visitor can see content on the page, but the site won’t respond to any of their actions until these other jobs are finished.
Looking back at the process of loading a page, a page’s “main thread” acts like a road where each of the files the browser has to download is a car on that road. On this road there are small, fast cars and there are bigger, slow cars and they’re all in one line trying to turn off the road (finish loading).
Input delays happen because a website has to wait for big, slow-moving semi trucks to get off the road before it can respond to a user’s interaction.
The user’s browser is essentially stuck in a big traffic jam.
Examples of First Input Delay
Here we’ll look at the Performance report available in Chrome Dev Tools for a few websites to see what could potentially be causing FID problems for people trying to visit those sites.
In the screenshot below, the gray bars shaded in red represent long tasks that occupy the main thread for longer than 500 milliseconds.
In this first example, we see that the main thread starts off the process of loading the page with 3 long tasks. The first takes 9 seconds to complete, the second takes 6 seconds to complete, and the third takes a bit more than 3.5 seconds to complete.
By reducing the number of scripts the browser has to download and execute, this site could turn all those big, slow trucks jamming up its main thread into lighter, faster cars that allow the page to respond to user interactions more quickly.
In this screenshot, we see another website that has fewer long tasks in its main thread, but still experiences issues with input delays.
By zooming in on the long task furthest to the right, we see that it’s actually several tasks grouped together.
This one task is made up of several scripts the browser has to download and run before it moves to the next thing. Each of these scripts is able to execute in just a few milliseconds (the longest is only 125 milliseconds), but they add up.
This is a highly interactive page with lots of bells and whistles that people can use to engage with the content so it makes sense there’s a fair amount of scripts that need to run in order to load the page. But all these scripts are actually making this page less useful to visitors.
Optimizing & debugging First Input Delay
The main culprits behind poor FID scores are JavaScript and images. Your best bet to fix (or avoid) FID is to optimize these files using minification and compression.
To find specific causes for First Input Delay, you’ll need to rely on a lab tool to identify and debug the exact issues.
There are 3 lab metrics you can use to debug poor FID scores for your website:
- First Contentful Paint (FCP): FCP is the amount of time it takes a browser to render the first piece of content when loading a page. It tells us how long a potential user might have to wait before they can start consuming page content.
- Time to Interactive (TTI): TTI is how long it takes a page to become fully interactive, which requires that “meaningful content” be displayed and the page responds to interactions within 50 milliseconds. It tells us how long a potential user has to wait before they can start fully using a page.
- Total Blocking Time (TBT): TBT is the time elapsed between FCP and TTI. This metric tells you if there are any browser tasks that take longer than 50 milliseconds to complete and “block” the rest of the page from loading. TBT helps you understand how interactive a page is (or isn’t) for potential users as it loads.
If your page’s main thread road has any cars that block a user from getting content or using interactive the page, or if it has any slow trucks jamming up the other cars, these three lab metrics will help you find them.
While first contentful paint, time to interactive and total blocking time aren’t exactly replacements for FID, analyzing these 3 lab metrics can tell you what tasks prevent potential visitors from quickly being able to use a page.
WooRank Reviews and Projects are lab tools that help website owners debug and optimize FID on their own sites.
Data regarding performance for First Contentful Paint, Time to Interactive and Total Blocking Time is shown in the Performance section for a page’s review. This data and analysis tells you what large, slow files prevent your site from fully loading and becoming useful as quickly as it should.
From here, it’s a simple step for you or your dev team to improve performance and your site’s First Input Delay score.
Measuring and Tracking FID
In our guides to measuring data for Core Web Vitals, we discussed the concept of “field” vs. “lab” data:
- Field data is collected from real users who visit a page out on the web. Google makes its field data available through the Chrome User Experience Reports, which includes data for websites in the CrUX database.
- Lab data is measured through tests conducted in controlled environments, generally using software and other technologies, on predetermined devices and connections. There are no real users involved in lab data.
Because FID requires an interaction from a website user, Google makes FID data available only through its field tools:
- Chrome User Experience Reports.
- Google Search Console Core Web Vitals Report
- PageSpeed Insights
However, these Google tools only work if your website is included in the CrUX database, which isn’t guaranteed. Even if Google has crawled and indexed your site, you might still not get field data for FID or the other Core Web Vitals if your site doesn’t get enough traffic within a certain time frame.
The WooRank Assistant, on the other hand, collects its own field data as soon as it’s installed on a website. It doesn’t rely on Google’s CrUX reports and so isn’t limited in terms of what FID data it can provide.
WooRank subscribers who have installed the Assistant on their site will be able to monitor their site’s performance for First Input Delay (plus all the other Core Web Vitals and a bunch more metrics) the second their sites start getting visitors.
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.
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.
By incorporating FID (and the other Core Web Vitals) into the search ranking algorithm, Google has further blurred the line between development, SEO and digital marketing. Starting any project off on the right foot requires all three functions to work in tandem now more than ever if you want to achieve your desired results.
The WooRank Assistant helps identify issues on a page-by-page basis and has recently been updated to include the three CWV checks, helping you to ensure your users have a great on-page experience.
Published by
