First Input Delay is an API that measures how long it takes for your site to react after someone interacts with it. In this article, learn what First Input Delay is, how to measure your website’s First Input Delay and how to solve common First Input Delay issues as explained by Patrick Kettner, Developer Advocate for Google.
Improving First Input Delay
Perfecting your first input delay is key to an excellent page experience. It can be frustrating when trying to browse a website, use an app, or watch a video interrupted by delays. In addition, delays can break up our thought process, make it harder to focus and complete goals making it essential to make sure the people using the site have as few delays as possible.
What is First Input Delay (FID)?
First input delay or FID is a new web API that measures how long it takes in milliseconds for your site to react after someone interacts with it. For example, when a website visitor clicks on a button or taps on a text input, Google measures the delay in processing data and interactions. Another way to think of it is how long it takes for your page to feel interactive and responsive to the user the first time they use it.
How to Find My Score?
Like every part of page experience, each of the URLs on your site are scored on first input delay based on the actual users using your site. Your homepage may have fantastic values, but your product page or articles could be far from perfect. Regardless of how any page performs, neither result impacts how another page performs on page experience.
Every URL is an island. However your pages are scoring, the numbers that you see reflect what users are experiencing. This is because the FID score comes from the monthly chrome user experience report.
Since FID is about how your site reacts to interactions, real users need to get an accurate measurement. As a result, you can only rely on user measurements from real-world users via your own analytics or the ones you can access inside the core web vitals report section of the search console.
Users can create a free account to access the Google Search Console, which offers information about how your website performs with page experience and other foundational pieces to creating websites. For example, the search console allows users to quickly check out how pages are performing with page speed insights, an online version of the same lighthouse tool part of the chrome dev tools.
What is a Good FID Score?
Like all the core web vitals inside of page experience, there is no such thing as passing or not passing. Instead, core web vitals are used as guides that Search uses to create relative performance differences between URLs to see how they perform against one another.
Generally speaking, a good goal is to have about 75% of your site’s visitors have a first input delay of less than 100-milliseconds. 100-milliseconds has been considered the point at which people perceive user interfaces as behaving instantaneously. Anything in the 100 to 300-millisecond range starts to become problematic and anything beyond 300 milliseconds is a noticeable delay, likely causing a worse experience for users.
It is important to note that you are not guaranteed to have an FID value since it is inherently based on user interaction. For example, if your page doesn’t interact with or people who don’t click on buttons or inputs, a FID value will not be recorded.
What if it is a New Page?
If your pages are new or your URLs haven’t been included inside the chrome user experience report, you can still figure out your FID results.
What is My FID?
Since the field data and page experience comes from your actual real-world users, site owners can figure out the FID themselves using the same APIs by adding javascript to the page. All of the core web vitals are available via javascript APIs, specifically through performance observers. These observers give an event or list of events that match the type of performance events that Google is interested in.
Since Google is looking for the first input, once the browser determines a first input has happened, it will execute the function that we pass it, passing us the list of events that match what we’ve requested. Though the first input will likely only have one event, the performance observer always passes a list of events to our callback. Then, the code iterates over the responses by calling git entries. For every entry, we look at the processing start and subtract the start time. The difference lets us know how long the first input delay was. You can take these numbers and send them up to your own analytics infrastructure to get a good idea of what our FID results will look like.
If you are having trouble bringing down some of your results, tracking in your own analytics can let you do a much more detailed data analysis allowing you to look for patterns such as user location, device type, or other information that may not be as obvious to compare and contrast on the official page experience results.
However, it is important to note that while these are close and potentially identical values to the FID results, several edge cases could make it slightly different.
FID Issues and Solutions
There are a few things to know about FID issues. By definition, any delay that is occurring will be related to javascript running on your page. All of the code on your page runs in the same thread by default, meaning that the browser can only do one single thing at a time. A code may take longer than expected since everything is blocked, even actions that people using your site may be trying to do. This could be because you have a large chunk of javascript that is being parsed or loaded when the page is initially loaded up. An event handler could be blocking something on heavy or is slow due to too much code.
If you are seeing issues with first input delay, check to see if you are loading too much javascript. Anything larger than 200 kilobytes is pretty large. If too much javascript is the issue, code splitting can help. Code splitting is a feature built into all modern javascript bundlers that allow you to split code into smaller chunks, ensuring that you are not blocking the rest of your page from reacting to the user’s input.
After splitting, any code that isn’t essential for page load should be loaded using the async or defer attributes on their script tag. By using defer, you are telling the browser that the script will not change the page’s layout, so it shouldn’t block the rendering of the page while it is being loaded or parsed.
Async is a lot like defer. It only takes it a step further, saying not to wait on any other scripts. Using the async attribute tells the browser to execute your code without blocking any other script beforehand.
Look Out for Code that Can be Deleted
While digging into the source code, be sure to be on the lookout for code that can be deleted. It can be easy to include polyfills or workarounds long after they’re actually needed accidentally. Often, the first interaction a user has with a page will be something at the top of your page, like a menu button or search input. If you are having issues with first input delay but aren’t sure why your score is what it is, it is good to start tracking the elements on your page that are having their delays being measured. If looking at the code snippet, you were working on before having access to APIs off of that same entry object.
Specifically, the entry target lets us know that the element we were interacting with whose delay is measured. This can be helpful if you have many link buttons or other clickable tappable elements on your page but aren’t sure which one is dragging your scores down. Once we track what target is associated with people having a slower first input delay, you can start to dig into your site’s code to understand what events are tied to it and any listeners attached to it.
Breaking Up Longer Tasks
Even if your code does not need to be split up, your tasks may still need to be. Tasks are things that your code is doing, whether it be laying out your web app, downloading states, or reacting to user input. A long task is anything that takes longer than 50 milliseconds to complete.
If you have issues with FID then looking at your long tasks is a great starting place to see where improvements can be made. Long tasks are highlighted in the chrome dev tools. Suppose you want to start looking for these on your user devices to build up a correlation between page experience results and long tasks in the field. In that case, you can programmatically access them just like looking at the first input event before. We create a performance observer then observe the long task type. From there, we can iterate over every instance to look into each attribution, giving us a bit of insight into the functions that may be long-running.
Devtools is a much better developer experience. Still, this API allows you to collect this information from your users and your analytics so you can track down correlations that may be otherwise hard to find in your local dev setup. Once you’ve found a long-running task, the next step is to break it up into smaller asynchronous functions. This can be as simple as wrapping code into set timeouts or requesting animation frames.
Conclusion
Improving first input delay comes down to optimizing the when, where, and why of the javascript on your site. Of course, you want to try and reduce its usage to the minimum needed to maximize your site’s potential page experience is new, but the ideas behind it are solid and user-focused. If you can get great results, then the visitors to your site will be all the happier.