An Explanation of First Input Delay

An Explanation of First Input Delay
First Input Delay is a Google metric that forms part of the Core Web Vitals. As part of the Page Experience Algorithm Update, this is likely to become a ranking factor later in 2021.

Definition of First Input Delay

FID is measured in milliseconds (ms) and is the time from when a user first interacts with a web page (such as clicking on a link, tapping a button or another JavaScript-based action etc.). to when the browser responds to that action. It is a measurement taken from when the user first clicks an element. You may also see an Agg. FID score (aggregated FID ) in the Page Speed Insights report; this means that 75% of URLs in the group has this score or better.
To put it another way, First Input Delay helps you make sure that the loading of any critical resources doesn’t make your website feel cumbersome and unresponsive.

Why the FID Matters

The FID matters most when the user needs to perform an action (click a video, start a quiz), as that is when the page is classed as becoming interactive. It is helpful as it allows us to see how clunky users may perceive the page while loading. Please note that the data collected via FID can vary dramatically depending on various factors due to different network conditions and capabilities of devices.
first input delay
A poor FID is often caused by images or scripts that download in a disordered manner, causing the page download to pause and restart. Picture this being similar to a traffic jam.

How to Optimise for First Input Delay

A great way to resolve First Input Delay issues is to ensure your CSS files are downloaded and parsed as soon as possible so that the browser can render the page’s layout.
However, JavaScript execution is one of the main culprits here. This is because: 
  • Long tasks that are executed sequentially,
  • They can have poor interactivity optimisation,
  • They can block main thread actions, 
  • They can lead to longer JavaScript execution times. 
For these reasons, I would suggest looking at ways to break up long JS tasks into smaller, more manageable, asynchronous tasks. For clarity, a long task is any code that could block the main thread for 50 ms. Once code is more manageable, lazy-loading can then also be used to speed up execution.
Problems with third-Party scripts can have a considerable impact on FID. I have seen many websites that use analytics and various tags from third parties, which may be considered best practices, but also put pressure on the network and result in the main thread becoming unresponsive after short periods. In this instance, you could investigate the on-demand loading of third-party code and prioritise the loading of content that will offer the most value to the user first.
Deferring the use of unused JavaScript will also help reduce or remove render-blocking JS and ensure that only code that is essential to the loading and interactivity of the page is loaded first.

Tools for Measuring First Input Delay

First Input Delay is a metric that can only be measured in the field because it needs a real user to interact with the page. Therefore FID cannot be measured in the lab. However, TBT is lab-measurable, and the two do have a reasonable correlation, so please see my post on Total Blocking Time for more lab measuring tools.
Google lists the following as field tools for measuring First Input Delay:
Share on facebook
Share on twitter
Share on linkedin