First Input Delay (FID): Think of the Elevator Button


First Input Delay (FID) is a Google Core Web Vitals metric designed to measure the time between a user’s first interaction with a page and the browser’s response. You can liken it to calling an elevator: FID would be the time between pressing the call button and it lighting up, signifying a response.

Along with LCP and CLS, FID is intended to provide a better understanding of the real experience users have on the website, and helps you identify opportunities to improve it.

But how does that affect user experience, how do you recognize a ‘bad’ FID score, and how do we go about improving it? Let’s break it down.

This article explains in further detail what FID is and how it affects your site performance. If you’re new to CWV, we recommend first checking out our Guide to Google Core Web Vitals.

FID: What Does it Really Mean?

According to the Web Dev Blog “First Input Delay measurpes the time from when a user first interacts with a page to the time when the browser is actually able to respond to that interaction.”

But in order to understand what FID really means in a performance sense (and why it’s important), we first have to understand how it works:

  • FID doesn’t measure when a website becomes interactive, there is another metric for that — TTI. Instead, it measures how responsive the website was when the first interaction happened. First input usually happens way before a page becomes completely interactive.
  • By ‘interaction’ we mean there is a ‘completable action’ a user can take, such as clicking a link, tapping on a button, or pressing a key (not scrolling or zooming).
  • FID only measures the ‘delay’ in event processing (the time in between clicking a button and the event being processed). It does not measure the event processing time itself, nor the time it takes the browser to update the UI after running event handlers.

Think of the Elevator Button

So, with that being said, let’s bring back the analogy of the elevator button:

You approach an elevator its call button is not illuminated. You push the button, it lights up, and you know you called the elevator successfully.

It might take it a while to get to your floor, it might be packed when it arrives and you won’t be able to use it — but from the moment you saw the button light up, you knew that your action had been responded to. 

This is what FID is intended to measure—the responsiveness of the website. The time it takes for something to happen after you first interact with a page (i.e, the button illuminating after interacting with the elevator). 

There will hopefully be many more interactions with your web page, but this first experience is a critical one — so we need to make sure that the user doesn’t feel any lag.

Think about pushing the call button on our hypothetical elevator and nothing immediately lights up. Your assumption may immediately be that it’s out of order, and if there is an extended delay, your trust that the elevator is safe and stable to use is going to be affected.

What Makes for a Good FID Score?

So that’s all well and good, but how do we actually figure out what a ‘good’ FID score is. How fast should that elevator button light up once we’ve pushed it?

On the surface, it’s very simple. Google recommends keeping FID under 100ms.

This recommendation is actually true for any other interactive user interface too, as it reflects how our brain works.

If we push an elevator button (hypothetical or real), and it lights up in 100ms or less we perceive it to be ‘instantaneous’. After 100ms we notice there is a delay, and after 300ms it feels like something is not working properly.

Did You Know: 100ms isn’t only the time-frame in which we consider something to be ‘instant’, it’s also the same amount of time it takes most people to blink!

But, as you probably guessed, things aren’t always that simple.

Depending on the exact moment when the interaction happens, delays might significantly vary for each user. This means it’s not possible to keep it consistent all the time, all you can do is increase the chance that their interaction will be processed quickly.

A good and realistic goal here would be to set a performance budget that achieves the 100ms target for least 75% of page interactions.

Learn more about the 75% percentile confusion and the importance of Real User Monitoring (RUM) data in Core Web Vitals.

How to Measure FID

As FID is a purely user-centric metric, it requires data based on real people interacting with an actual web page. Here are a few reports that can give you an accurate reading for FID:

Field Data section in Google PageSpeed Insights

Google PageSpeed Insights (GPSI) provides a distribution graph of what percent of people have a good experience — if the site provides FID under 100ms for 75% of users or more — it’s considered to be a good result.

Core Web Vitals tab in Google Search Console 

You can also use the Core Web Vitals Tab in Google Search Console to access Real User Monitoring (RUM) data for your site alongside other Core Web Vitals. Search Console comes in handy to see the complete picture and specific URLs there might be an issue with.

Both of these tools use data that Google was able to collect about the experience users had on your website during the last 28 days and come from Chrome User Experience Report (CrUX).

Regardless of the tool that you use, bear in mind that numbers in reports should always be analyzed altogether, in the connection with each other.

How Do You Improve FID?

User events and paints in a browser are processed one after another inside a one-lane tunnel called the browser’s Main Thread.

If our hypothetical elevator is busy at the moment you push the call button, it won’t come to your floor right away—it needs to finish its current task (stopping on another floor) and only after that it becomes available to come to the floor you are on.

The same happens with websites. In order to process a user input (a link clicked, a tap, a key pressed) there needed to be a gap to fit it in.

If user A clicks a link at the moment when the Main thread is free (idle) their interaction gets processed immediately. If user B clicks the same link while the Main thread is busy, their interaction will be processed only after the current task is finished.

Therefore, all we need to do to improve FID is to make the main thread less busy, increasing the amount of idle time. This increases the chance that the user input gets to be processed without delays, hitting that 100ms goal. We can recognize this in GPSI as the “minimize the main thread work” recommendation.

The Break-Down

  • FID measures the amount of the time between the first user interaction on a page (like a click, tap or pressing a button) and the moment it gets processed by browser.
  • If it takes longer than 300ms it feels like something doesn’t work properly, and as it is the first experience user has on the website it heavily impacts the impression in general.
  • That’s why it’s important to keep to FID under 100ms (which feels instantaneous) for at least 75% of users.
  • FID gets longer if clicked while the Main thread is busy, so the more you are able to minimize the main thread work, the higher chances for FID to stay under 100ms for the major part of users.
  • It’s important to analyze FID numbers in the connection with other metrics, and to apply the same approach when optimizing performance — in most cases it’s more beneficial to focus on improving overall performance than targeting a specific metric.

Improve your FID with XWP.

Our team is ready to help improve your website performance. Talk to one of our experts today to learn more about what we can do to help grow your business.