First Input Delay: A Complete Guide to Optimizing FID

First Input Delay (FID) is one of the Core Web Vitals metrics. It calculates the delay between the first user interaction with your page and the moment the browser can start processing that interaction. It’s an important measure of your website’s loading speed, which Google uses as a minor ranking factor.

What is the First Input Delay (FID)?

First Input Delay is a real-user web performance metric that tracks the time between the moment a user first interacts with a web page after entering it to when the browser can start processing that interaction (when the browser’s main thread is idle).

The time between these two events is called input delay (also known as input latency.)

In other words, FID reflects the latency between the user interaction (when you click or tap on something like a link or a button) and the time the browser responds to your action and starts processing it. 

Imagine visiting an online store and expecting a given element to open on the spot. However, the hyperlink you clicked on might not respond immediately. Technically speaking, this is because the browser’s primary thread is processing a different request.

The events that count as user input measured by FID must be discrete (finite). Continuous types of user interaction, like zooming or scrolling the page, can’t be accurately measured using this metric. This is because they often don’t run on the browser’s main thread and have different constraints.

FID only measures the first user interaction

FID is about first impressions, making it a user experience metric. The first time a user interacts with your page is fundamental in their experience and perception of your web performance.

Furthermore, most of the blocking of the browser’s main thread occurs in the first moments of a web page’s life cycle – that’s when critical resources are loaded. FID is a metric that helps you address that and ensure that loading those critical resources doesn’t make your website feel clunky and irresponsive.

FID measures input delay, not processing

The actual processing or updating of the web page as a consequence of that interaction is not measured by FID. That’s because it would be easy for developers to game FID by separating the event handler from the task associated with the event.

Why does input delay (a.k.a. input latency) happen?

Input delay occurs when page elements, like images or scripts, are loaded without a user request.

According to Google, one of the reasons behind long input delays is JavaScript execution. In particular, it applies to large JavaScript files the browser must execute before running any event listeners.

Why? Because the JavaScript code that is being loaded can change the subsequent actions of the browser.

It can make the website feel unresponsive as the browser waits to determine the next steps, contributing to the long input latency. It feels like the browser is stuck in a traffic jam that can be streamlined by minimizing JavaScript files. It can reduce the time it takes for the browser to register an event.

Input delay varies for each user

The First Input Delay score is unique for each visitor to your website. Some visitors may get distracted more easily and stop browsing your page until they can quickly interact with the content. 

And while the score differs for an individual’s interaction with the site, also not all visitors’ actions are considered relevant to the score. That’s why Google understands it’s normal for not all visitors to interact with your site within a single visit.

Is First Input Delay the same as Time to Interactive?

Time to Interactive (TTI) measures the time it takes for a page to be fully interactive, while First Input Delay (FID) tracks user input before the page is fully interactive.

Time to Interactive is registered when there’s valuable content already rendered on the page (measured by First Contentful Paint), event handlers are registered for most page elements, and user interaction is processed within 50ms.

Time to Interactive is displayed in Lighthouse.

Meanwhile, First Input Delay can track, for example, when a user clicks on a link that appears before event handlers are registered for most page elements. First Input Delay, unlike Time to Interactive, allows you to capture those early, critical interactions.

Why is First Input Delay (FID) important for SEO?

1. First Input Delay is one of the most exciting web performance metrics as it is purely a Real User Metric. It cannot be simulated in a lab test since it requires real user input to be measured. FID is about the experience of real users when they enter your page.
2. As a Real User Metric, it’s great to monitor and optimize as it defines your website’s User Experience.
3. First Input Delay is now an official ranking factor for Google. First Input Delay is the metric that tracks a website’s responsiveness, while CLS tracks visual stability, and LCP tracks loading speed. Google made Core Web Vitals a part of its ranking algorithm when it went live in June 2021.

In other words, there are plenty of reasons to focus on First Input Delay optimization on your website.

Do you want a deeper understanding of FID, CLS, and LCP? Find out more about them in our ultimate guide to Core Web Vitals.

What’s a good FID score?

Studies show that a delay of 100ms is perceived as caused by an associated source. 0.1 seconds is about the limit for having the user feel that the system is reacting instantaneously.

For these reasons, it’s good to try and keep your FID under 100ms.

Here are the thresholds that Google set for FID in PageSpeed Insights:

• FID of 100ms or less is considered good,
• FID of between 100-300ms needs improvement,
• FID above 300ms is considered poor.

Keep in mind that the browser still needs to run the task associated with the user input, which FID doesn’t measure. So in some cases, your FID might be under 100ms, but the page may still feel a little irresponsive.

How to improve the First Input Delay score?

If you’re unsatisfied with your FID score, it usually indicates that you need to improve your JavaScript or CSS usage.

Here’s how you can proceed with your First Input Delay optimization.

Optimize your CSS code

When it comes to CSS files, they need to be downloaded and parsed as soon as possible so that the browser can render the layout of the page. Because of that, your options for reducing the impact of CSS on your First Input Delay are limited. However, you can refer to the best practices, such as minifying and compressing your files or removing unused CSS code.

Optimize your JavaScript code

JavaScript tasks are usually the culprit when there’s a long input delay. Blocking the browser’s main thread for extended periods, they don’t let it process user input.

Here’s when you can take advantage of JavaScript SEO services.

Also, below are some strategies you can use to minimize the time the main thread is blocked by the JavaScript execution:

Create small, asynchronous tasks

Long tasks block the main thread, not allowing it to process user input. If you break them up into smaller tasks, user input can be processed between them. Try to keep your tasks under 50ms to be safe.

Generate server-side content

Aim to minimize how much data needs to be post-processed on the client-side. That reduces the amount of work that has to be done by the browser to render a page.

Explore the on-demand loading of third-party code

Third-party code, such as tags or analytics, is often responsible for unnecessarily blocking the main thread. While sometimes analytics need to be loaded at the very start to ensure the whole visit is tracked correctly, you’ll likely find third-party code on your page that doesn’t need to be run immediately. Prioritize loading what you believe offers the greatest value to users first. 

Use web workers

You can delegate some main thread work to web workers to reduce the workload on the main thread. Web workers allow you to delegate some of your JavaScript code to be run on the worker thread, which means less work for the main thread and less input delay.

Defer unused JavaScript

Use async or defer so JavaScript is executed only when it’s needed. If you’re using modern JS, configure ES6 modules to load on demand.

Minimize unused polyfills

Polyfills are needed when a user is using an older browser. Developers use them to build websites with modern JavaScript and still deliver all functionalities to browsers that don’t support some of the modern features.

Make sure that polyfills are not run if they are not needed. Deliver separate bundles using module/nomodule.

Do you want to know more about optimizing your JavaScript code? Start by reading about the foundations for successful JavaScript SEO.

Idle until urgent

Idle until urgent is a code evaluation strategy conceived by Philip Walton from Google.

This strategy takes elements from the two most popular approaches to code evaluation – eager evaluation and lazy evaluation. 

Eager evaluation means all of your code is run right away. This approach results in a page that loads for a long time until it’s fully interactive but then runs smoothly without any hiccups.

Lazy evaluation is the opposite approach – your code is run only when it’s needed. While it has its benefits and might be useful for some websites, lazy evaluation means that you risk having input delay once the code needs to be run.

Idle until urgent takes the best aspects of both approaches to provide a clever way to evaluate your code, so input delay is minimal.

Idle until urgent lets you run your code during idle periods, using the main thread to the fullest extent possible. At the same time, it guarantees that urgently needed code is run immediately. 

To get into the details of this code evaluation approach, read Philip Walton’s article and get familiar with the idle-until-urgent JavaScript library.

Taking the idle until urgent approach is a great way to improve your First Input Delay. Since code execution happens during idle periods only, you minimize the main thread blocking time.

How can you fix the input delay?

Long input delay (input latency) is a problem when the browser takes too long to respond to a user’s interaction with a website, such as clicking a button or link. To fix this, you can use HTML attributes to control how scripts are downloaded (reorder the script files and optimize images in the code) or remove unnecessary scripts.

How can you measure FID on your page?

First Input Delay can be analyzed based on the field data from the following tools:

• Chrome User Experience Report through BigQuery (origin level) or the CrUX API (both the origin and URL level)
• PageSpeed Insights
• Search Console (Core Web Vitals report)
• Firebase Performance Monitoring.

How to measure FID with JavaScript?

You can also measure FID by adding JavaScript to your page.

There are two ways of doing that:

• Using the web-vitals JavaScript library.

Add the following code to your page to have FID printed out in the console:

import {getFID} from 'web-vitals'; 
getFID(console.log);

• Manually adding a PerformanceObserver to track input.

You can also use the Event Timing API to track FID manually if you don’t want to import the web-vitals library. 

This code was provided by Philip Walton in his article on FID published on web.dev.

let firstHiddenTime = document.visibilityState === 'hidden' ? 0 : Infinity;
document.addEventListener('visibilitychange', (event) => {
  firstHiddenTime = Math.min(firstHiddenTime, event.timeStamp);
}, {once: true});

function sendToAnalytics(data) {
  const body = JSON.stringify(data);
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

try {
  function onFirstInputEntry(entry, po) {
    if (entry.startTime < firstHiddenTime) {
      const fid = entry.processingStart - entry.startTime;
      po.disconnect();
      sendToAnalytics({fid});
    }
  }

  const po = new PerformanceObserver((entryList, po) => {
    entryList.getEntries().forEach((entry) => onFirstInputEntry(entry, po));
  });

  po.observe({
    type: 'first-input',
    buffered: true,
  });
} catch (e) {
}

Max Potential First Input Delay – the worst-case scenario

First Input Delay can vary heavily depending on when the user first interacts with a page because the browser’s main thread isn’t equally occupied throughout the page’s lifecycle. As a result, some users may experience no delay at all, while others may be strongly discouraged by it, depending on when they first interact with the page.

For that reason, it may be helpful to monitor your page’s Max Potential First Input Delay (MPFID). It’s the duration of the longest task run on the main thread after First Contentful Paint is registered.

By measuring the duration of that task, you simulate the potential situation where the user interacts with the page just as this long task is starting and has to wait until it’s completed for the input to be processed.

Optimizing MPFID involves various strategies that reduce the running time of your longest task or break it up into smaller chunks.

MPFID is a lab metric included in Lighthouse. To see it, export the Lighthouse report for your page to a JSON file.

Can you measure FID in Lighthouse?

No, you cannot measure First Input Delay with lab tools like Lighthouse. 

It requires a real user’s interaction to have an input event to register. However, you can use a different metric that strongly correlates with FID. 

Total Blocking Time (TBT) is an example of a metric you can measure in the lab. If you improve your TBT, you’ll most likely improve your First Input Delay.

TBT measures the time between First Contentful Paint and Time To Interactive when the main thread was blocked from responding to user input.

You can also use Time To Interactive as a similar point of reference.