First Input Delay

First Input Delay (FID) measures how long it takes for the browser to start processing a user interaction, like a click or tap on the page. A page that responds quickly to user input provides a better user experience.

FID is one of the Core Web Vitals that Google uses in its search rankings. The First Input Delay of your website is good if 75% of your mobile users experience input delays under 100ms.

What is First Input Delay

First Input Delay happens when a user interacts with a page while the CPU is already busy doing other work on the page. It measures how much time elapses between when the user first interacts with the page and when the CPU becomes idle, i.e., when the event handler for the user interaction starts running.

The time spent running the event handler does not count towards FID, so if your CPU is idle the First Input Delay will always be 0ms.

Diagram explaining First Input Delay

A First Input Delay is only measured if the user interacts with the page, otherwise no value is recorded.

What counts as user input?

User input includes clicks, taps, and key presses. A delay is captured if an event handler is delayed, or if an HTML element responds slowly for other reasons.

For example, clicking on a text input requires the page main thread to be idle, even if no custom JavaScript code runs in response to the click. This also applies when clicking on a link or dropdown.

What's a good First Input Delay?

On a mobile device, Google says a First Input Delay under 100ms is good, up to 300ms needs improvement, and more than 300ms is poor.

Relationship to Total Blocking Time

First Input Delay can only be measured if the user interacts with a page, so it can only be measured in the field with real users. Lab-based tools like Lighthouse instead report a metric called Total Blocking Time (TBT).

A CPU task counts as blocking time when it takes longer than 50ms to run. If your TBT is 0ms then the your First Input Delay will be under 50ms, as long as your real users use a device with a similar performance to the lab tool.

When a user tries to interact with a page while the CPU is blocked they'll experience a delay in how quickly the page responds to their input.

Diagram explaining Total Blocking Time and it's relationship to First Input Delay

How to reduce First Input Delay

Make your page finish loading quickly

You can prevent input delays by fully initializing your page before the user tries to interact with it. Reduce the download size and JavaScript execution time on your page to achieve this.

Optimize first-party JavaScript

Reduce the amount of JavaScript running on your page, for example by speeding up your application code, using faster JavaScript libraries, or by lazy-loading coded that isn't necessary right away.

Reduce third-party scripts

Third-party widgets can often load and execute large amounts of code, blocking the page main thread. Avoid loading too many third-party scripts and search for alternatives if a third-party is particularly slow.

Communicate to the user that the page isn't ready for interaction

As a field metric, First Input Delay depends on the behavior of your users. A delay is only recorded if they try to click somewhere on your page. If you communicate that a part of the page isn't fully loaded yet – for example using a spinner or by graying out the UI – you can avoid unexpected interaction delays.

Measuring First Input Delay with the Event Timing API

The Event Timing API allows you to measure the First Input Delay in the browser. You can then send this data to your analytics software.

The following code snippet prints the First Input Delay in milliseconds:

const po = new PerformanceObserver((entryList) => {
  const entry = entryList.getEntries()[0];
  const firstInputDelay = entry.processingStart - entry.startTime;
  console.log({ firstInputDelay });
});
po.observe({ type: "first-input", buffered: true });

First Input Delay in PageSpeed Insights

PageSpeed Insights uses data from the Chrome User Experience report to show the First Input Delay experienced by real users of your website.

It also runs a lab-based test that reports the Total Blocking Time.

FID in PageSpeed Insights

Monitoring page interactivity with DebugBear

You can use DebugBear to continuously measure page performance in a lab environment. This lets you keep track of Total Blocking Time and CPU tasks that could block user interaction.

Total Blocking Time and CPU tasks in DebugBear


Still need help? Contact matt@debugbear.com for support.
DebugBear is a website monitoring tool built for front-end teams. Track performance metrics and Lighthouse scores in CI and production. Learn more.