Core Web Vitals - FID - First Input Delay

First Input Delay (FID), one of the three core web vitals, is all about interactivity. What exactly does this metric describe? How is it measured? Why do we use it? Let's have a closer look.

What is FID?

Basically FID describes the time it takes from the user's first interaction with an element on the site until the relevant action starts processing. Such an element can be a button, a link or any other element that allows for interaction. It's important to note that the processing time of the event is not included in FID, instead the measurement stops at the start of the processing of the event.

Why should we care about FID?

It's actually easy to imagine why this metric is user-centric and how it impacts a user's experience. Imagine you're visiting a website, it loads just fine and a button you want to click is on the screen. You click it and... nothing happens... is the site broken? Then, after 300ms the page starts to respond. Not exactly a great experience. Especially if you are of the impatient kind and clicked the button again or decided to try another element in the meantime.

What is a good FID?

A FIP below 100ms is considered to be good.

Above 100ms and below 300ms needs improvement.

And anything greater than 300ms is considered bad.

Now when it comes to actually measuring FID, things get interesting. Interactions will only occur once a relevant element finished loading, obviously visitors can't click anything they don't see and to add to the complexity, the input delay can vary depending on the exact time the user clicked.

At one moment in time, the browser might be busy processing a small task and will respond quickly to a user's click, while a few moments later, the browser started processing a huge task and FID will be much morse.

Let's look at some examples.

Examples of FID

[AAAABBCCCCCCCCCCCCCCCDDDDDEE]

Let's assume our browser deals with a few tasks when the website loads. Tasks A, B, C, D and E could be anything, from rendering, to script or CSS parsing.

If a visitor clicks during this time, the browser first has to finish the current task and will then deal with the user's action, leading to different FIDs. Let's see some examples:

[AAAABBCCCCCCCCCCCCCCCDDDDDEE]
[X---O                       ]
[   XO                       ]
[    X-O                     ]
[          X----------O      ]
...

X is the user's click.
- the time the browser is still busy with another task
O the browser starts processing the action

As we can see our first input delay is actually dependent on the time of the input and the task the browser is currently processing.

What causes a bad FID?

We just saw that FID is influenced by how much a browser needs to process and how big the tasks are.

A bad FID is therefore a sig nof the browser processing too much. We can improve this by

• reducing the impact of third-party code
• reducing JavaScript execution time
• minimizing main thread work
• Keeping request counts low and transfer sizes small

Where do we find our FID? How can we test it?

If your page is already out in the open and people are using it, Google's search console can give you information on your FID.

Otherwise, for lab style metrics (ones which we can test in an controlled environment), we can't exactly test for FID, but Google's Lighthouse gives us the Time To Interactive (TTI) metric, which is often used as a substitute.

If you enjoyed this article, you might also want to check out some of my other blog posts on Core Web Vitals: Core Web Vitals - CLS - Cumulative Layout Shift
Core Web Vitals - LCP - Largest Contentful Paint
Core Web Vitals - E-commerce\

Sources:
web.dev