First Input Delay (FID): How It Works, Debugging, and Improving

First Input Delay (FID) is an important web performance metric that measures the time from when a visitor first interacts with a web page to the time when the browser responds to the interaction. A long delay here can give visitors the impression that the website is slow or unresponsive, and it can contribute to a higher bounce rate. Google adopted FID as one of its Core Web Vitals, making FID scores of great importance for achieving higher search engine rankings.

This article will help you understand FID, how to identify issues contributing to a large FID, and some tactics for fixing these issues in your website. Whether you’re a non-technical webmaster or a seasoned software developer, this piece will give you a solid starting point for understanding and fixing FID issues.

Understanding FID (First Input Delay)

As mentioned, FID measures the responsiveness of your website. It’s measured by calculating the time between a user's first interaction, such as clicking a button, and the browser's response time. FID is measured in milliseconds, and in general, an FID of 100 milliseconds or less is ideal for usability and search engine optimization.

Why FID is a Crucial Metric

Organic traffic from search engines is a fantastic way to gain users, revenue, and brand awareness, and many businesses rely on it. FID is an important ranking factor for search engines like Google and Bing, so it’s important for businesses prioritizing search engine optimization (SEO) to pay attention to it.

That said, FID also influences usability - regardless of search rankings. No one likes a laggy website. When FID is high, users might think the website is unresponsive and are more likely to leave.

How FID Works

To understand how FID works, you need to know more about how browsers render web pages. Browser rendering begins once an HTTP response is received from the server where the website is hosted. Rendering happens in the following sequence:

1. Parsing HTML: The browser starts by constructing the Document Object Model (DOM) tree to build the structure of the page.
2. Fetching external resources: The browser loads the resources imported by the HTML page, like stylesheets, scripts, and images.
3. Executing JavaScript: If scripts are present, the browser executes them. While the scripts are running, the browser’s thread is blocked.
4. Rendering the page: The final step is when the browser renders the web page based on the DOM and the result of JavaScript code to display the content visually.

Browsers are single-threaded. In other words, they execute one task before taking up another. If the main thread is occupied during any of these steps (by long-running JavaScript or large external resources), the browser becomes unresponsive to user interactions, which will lower FID scores.

Identifying and Debugging FID Issues

FID in a simple HTML-only website is usually not a problem (unless there are server-side issues), but it comes up more often in single-page applications. Single-page applications (typically built on a framework like Angular or React) allow developers to build highly interactive and complex applications in the browser, but they require more JavaScript, meaning there are more opportunities for long-running, blocking scripts to show up.

You can use a few web-based tools to measure your site’s FID, identify issues, and implement fixes. Let’s look at some FID measurement tools and how you can use them to track issues down.

Tools for Measuring FID

The two most common tools that provide FID data are Lighthouse and Chrome DevTools.

Lighthouse is an open-source Chrome Extension developed by Google to audit the performance of web pages and provide insights into FID scores. It can be run on any web page, even if it requires authentication. Lighthouse includes five audit categories: performance, accessibility, best practices, progressive web apps, and SEO.

Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It provides data on various performance metrics, including FID in the Performance tab in Chrome DevTools. This feature enables you to record specific user actions and see which part of the frontend code takes a long time to execute.

How to Interpret FID Data and Locate Issues

The results of both Lighthouse and Chrome DevTools are color-coded. Green indicates good performance (FID less than 100 ms), yellow indicates needs improvement (FID 100-300 ms), and red indicates poor performance (FID more than 300 ms).

On Lighthouse results, the performance opportunities and diagnostics sections point to some of the issues that affected the page loading speed and the First Input Delay:

In Chrome DevTools’ Performance recording, you can see a timeline that includes all tasks and how long they took to execute. From this timeline, you can identify which tasks or resources are causing an input delay:

Understanding the 4 Main Causes of Poor FID Score

Generally speaking, FID issues are caused by long server load times or bugs in frontend code. To be more specific, here are a few common causes of poor FID scores:

Long Image and Video Load Times

If your site relies heavily on external resources like images and video, you can generally run into problems with page speed. The FID score will be negatively impacted if those external resources also trigger based on user inputs (like in image carousels or product detail pages).

Slow Server Response Times

The cause of delayed input can also come from server code execution. This issue is one of the most common and often hardest to debug, as there are so many factors at play. But, if your frontend needs a response from the server in order to react to user interactions, your FID score will go down, so it’s important to keep this in mind.

Blocking JavaScript

JavaScript in the browser that uses synchronous functions or has bugs can block the main thread. This can lead to a delay between a user's action and the browser's response because the browser will remain busy executing the JavaScript before it responds.

Complex Event Listener Operations

JavaScript event listeners override the default functionality of HTML anchor elements and buttons. If the tasks performed by an event listener involve complex background operations, such as processing and pulling real-time data, it can significantly reduce your FID score.

How to Identify and Debug FID Issues Using Chrome DevTools

Let’s see how to create a recording and use the Chrome DevTools Performance feature to analyze it.

First, open Chrome DevTools by right-clicking on your web page and select Inspect, or use the keyboard shortcut Ctrl+Shift+i on Windows/Linux or Cmd+Option+i on Mac.

Go to the Performance tab, and click the "Record" button at the top left corner.

During the recording, interact with your site as a user would by clicking buttons and scrolling. Stop the recording, and wait a few seconds for the results to appear.

The results show performance insights for resource loading, tasks, CPU, interactions, web workers, and more. Start by investigating the Main section, looking for tasks with red marks. Clicking on one of these red-marked tasks will provide more details about what was happening:

From this Long Tasks view, check the Bottom-Up or Call Tree tabs. This will enable you to identify which scripts take the longest to run and determine if they were written by you or a third party (e.g., an NPM library).

This information will guide you to the resources and code that need to be optimized. It will also help you decide which of the below strategies to apply.

Strategies for Improving FID Scores

Once you start identifying the parts of your site that contribute to poor FID scores, you can choose the right strategy. You may need to engage with your web development team to handle this, but some strategies (like optimizing image and video files) can be done by non-technical website administrators.

Break Up Long JavaScript Tasks

Long JavaScript tasks can block the browser’s main thread (remember, browsers are single-threaded, so they can only do one thing at a time), leading to delays after users interact with your page. Breaking up these tasks, using asynchronous functions, and running JavaScript only when necessary can help improve your FID scores.

You should also use the HTML defer or async attributes when possible. These attributes are used to prevent JavaScript from blocking the main thread and can affect the First Input Delay. The async attribute allows the script to run asynchronously as soon as it is available, while defer ensures that the script runs after the document has been parsed.

Optimize Image and Video Load Times and Priorities

Media files like images and videos are common factors in increasing page load times and blocking the browser’s main thread since they are the largest resources on most web pages. If a user interaction triggers a large image download, this can contribute to a poor FID score.

Some easy ways to optimize images and video are to use:

• Image Compression: The first step to take while optimizing media files is to reduce image size by using image compression. Reducing image file sizes leads to quicker load times.
• A Content Delivery Network (CDN): A CDN helps speed up the loading time of your resources. It stores your resource files on multiple servers. When a user visits a webpage, it loads resources from the location closest to this user.

Optimizing Server Response Times

To improve your server's response times, monitor and upgrade your servers as needed. You can also reduce the number of server requests you need on the frontend and optimize database queries. Caching can also be an easy way to improve response times for common calls, but then you have to worry about cache invalidation.

Finally, if you can’t fix server response times, you can use asynchronous calls on the frontend to prevent slow responses from blocking the browser’s responsiveness. This may require frontend re-architecture, but because you can never guarantee a server’s responsiveness, it’s typically a good idea to design your application with asynchronous calls in mind.

Use of Web Workers

Web workers provide a simple way for websites to run scripts in background threads. Since Web Workers don’t interrupt the user interface, you can prevent long tasks from blocking the main thread and causing high input delays. Web workers are especially useful for tasks that don't interact with the DOM, such as fetching real-time data or executing autosave functionality.

Web workers are created using the web workers API. The Worker objects can be created using a constructor that runs a specific JavaScript file. The following is a short sample showing how you can create a Web Worker, retrieve data using the onmessage event handler, then terminate it:

// Create a Web Worker
const backgroundWorker = new Worker("workerFile.js");

// Log the message received 
backgroundWorker.onmessage = (e) => {
  console.log(e.data);
  console.log("Message received from worker");
};

// Terminate the Web Worker
myWorker.terminate();

Utilizing web workers will require some frontend architecture changes, but they are a great way to prevent background tasks from contributing to a poor FID score.

Final Thoughts

First Input Delay (FID) is a crucial performance metric affecting user experience, conversion rates, and search engine rankings. In this article, you got an introduction to how FID works and the most common causes of poor scores. You also learned how to identify and debug FID issues and explored various strategies to achieve lower FID scores by re-architecting your frontend.

Positional is a modern toolset for content teams to scale their content channels faster and drive more traffic from organic search. You can book a demo now to gain access to Positional’s private beta.

‍