FID - First Input Delay

Introduction: Core Web Vitals

For years, web performance monitoring has been driven by "browser-centric" metrics. Even if some of them have been heavily used and are still useful today to some extent, as the Page Load Time, the main issue they have in common is their inability to provide accurate data about how real users experience their web journey.

In order to address this challenge, Google announced in May 2020 the introduction of brand new web performance metrics that form the Core Web Vitals.

These Core Web Vitals are focused on three important aspects of a real user experience:

"Interactivity" measurement with FID

The First Input Delay (FID) metric helps measure your user's first impression of your site's interactivity and responsiveness. It measures the time from when a user first interacts with a page to the time when the browser is able to react to it, meaning when it is able to begin processing event handlers in response to that interaction. A user's interaction can be clicking a link, tapping a button or using a custom, JavaScript-powered control.

When writing code that responds to events, developers often assume their code is going to be run immediately (as soon as the event happens). But as users, we've all frequently experienced the opposite: we've loaded a web page on our phone, tried to interact with it, and then been frustrated when nothing happened.

In general, input delay (a.k.a. input latency) happens because the browser's main thread is busy doing something else, so it can't (yet) respond to the user.

Consider the following timeline of a typical web page load:

The above figure shows a page that's making a couple of network requests for resources (most likely CSS and JS files), and after those resources are finished downloading, they're processed on the main thread. This results in periods where the main thread is temporarily busy, which is indicated by the beige-colored task blocks.

In this example, some of the main thread tasks are considered "Long Tasks". These are JavaScript execution periods where users may find your User Interface (UI) unresponsive. Any piece of code that blocks the main thread for 50 milliseconds or more is considered as a Long Task. When the first user's interaction happens near the beginning of such a Long Task, the browser's response to this action can be delayed, as it is shown on the following example.

Because the input occurs while the browser is in the middle of running a task, it has to wait until the task completes before it can respond to the input. The time it must wait is the FID value for this user on this page. Please note FID is only measured for the very first user's interaction.

What is a good FID score

To provide a good user experience, sites should strive to have a First Input Delay of less than 100 milliseconds. Everything between 100 and 300 milliseconds needs improvement and you can consider everything over that as performing poorly.

How to generally improve FID

The main cause of a poor FID is heavy JavaScript execution. Optimizing how JavaScript parses, compiles, and executes on your web page will directly reduce FID. This can be mainly achieved through the following best practices:

• Break up long-running tasks code into smaller, asynchronous tasks
• Optimize your page for interaction readiness (optimize first-party script loading, minimize reliance on cascading data fetches, minimize how much data needs to be post-processed on the client-side, explore on-demand loading of third-party code, ...)
• Use a web worker that makes possible to run JavaScript on a background thread
• Reduce JavaScript execution time by deferring unused JavaScript and minimizing unused polyfills