Have you ever experienced trying to click on a button or a link on a website but it doesn’t seem to respond right away? That small delay leaves a bad impression on users that may ultimately be the reason why they don’t visit more pages on your website or worse, not return at all.
In this third part of our Core Web Vitals guide, I will walk you through the second Core Web Vitals metric, First Input Delay (FID).
If you haven’t read what the Core Web Vitals are yet, I highly recommend that you read the first part of our guide first by going to this link.
And if you’re interested to read about Largest Contentful Paint, the first metric in the Core Web Vitals, I highly recommend that you go check out our guide for that as well.
What is First Input Delay?
First Input Delay or FID measures the time it takes for a page to respond to a user’s first interaction with it. It is a metric that focuses on the interactivity of a web page which means if a user did not interact with the page, FID is not measured.
To fully understand what FID is, let’s have a quick run-through of the loading process of a web page.
When you open a web page, the browser will make a couple of network requests from the website to load necessary files and then process it in the main thread. While the main thread is still processing CSS and JS files, some parts of the website may now be visible to the user. However, that does not mean that the website has fully loaded all of its functionalities.
First Input Delay is different from Time to Interactive (TTI) because TTI measures the time until the page is interactive, not the response time of the page to the interaction. First Input Delay happens between the First Contentful Paint (FCP) and Time to Interactive.
A good FID score is 100ms and below. Users will perceive loading speeds of 100ms and below as instantaneous.
Anything between 100ms and 300ms needs to be improved and scores above 300ms are considered poor. According to Google, a good threshold is 75% of the total page loads (mobile and desktop). However since FID is a metric that directly relies on human interaction with the page, they highly recommend looking at the 95 to 99 percent of page loads
Why the First Input Only?
I’m pretty sure you’ve heard of the quote “don’t judge the book by its cover”, well that’s not true when it comes to websites. The first impression of a user to your website has a huge impact, especially if they are a new visitor. A small delay can make your website feel clunky.
Also, according to web.dev, they have found out that most interactivity issues on the web happen during page load and they believe that focusing on optimizing the first user interaction will have a bigger impact on optimizing the overall interactivity of the web.
Although the first input delay is the main metric in the core web vitals, other interactions are also important but Google decided that it is best to separate the two metrics to provide web developers with more specific guidelines.
How is First Input Delay Measured?
FID is unique from other metrics because it is the only metric that can only be measured using field tools. You cannot use lab tools to measure FID because it requires real users to interact with your website.
Lab tools to measure First Input Delay:
- Chrome User Experience Report
- PageSpeed Insights
- Search Console Core Web Vitals Report
It is also important to note that only clicks on buttons and other elements are considered as input. Mouse scrolls or trying to hover your mouse on an image or text does not count as an interaction with the page.
This means that there will be times that some sessions will not have FID values.
What affects Poor First Input Delay?
Optimizing for First Input Delay
Avoid/Break Long Tasks
Any scripts that keep the main thread busy for 50ms or more are called Long Tasks. If you want to identify long tasks on your page, you can use the Chrome DevTools. If possible, avoid having long tasks but if not, you can split them up to reduce FID time. Long tasks also affect other metrics such as TTI so it is best to prioritize reducing them.
Utilize a Web Worker