Core Web Vitals Part 2: First Input Delay (FID)

Core Web Vitals Part 2: First Input Delay (FID)

1. QuikRead

We’ve all heard how vital it is to have a positive first impression. It’s crucial when meeting new people, and it’s also important when creating web experiences.
On the internet, a positive first impression will be the difference between someone being a lifelong customer and them quitting and never returning. The question is, what constitutes a positive impression, and how do you determine what kind of impression you’re going to have on your users?
First impressions on the web will take several different forms, including first impressions of a site’s architecture and visual appeal, as well as first impressions of its speed and responsiveness.
Although web APIs make it difficult to assess how much users like a site’s design, they make it easy to assess its speed and responsiveness!
The first experience users get on how quickly your site loads can be calculated using First Contentful Paint (FCP). However, how quickly the site can paint pixels into the screen is just part of the story. It’s also crucial to consider how responsive the site is as people want to interact with those pixels!
The First Input Delay (FID) metric measures the user’s first experience of your site’s interactivity and responsiveness.

2. What is First Input Delay (FID)

FID is the amount of time that elapses from when a user first communicates with a page (e.g., when they press a link, tap on a button, or use a custom, JavaScript-powered control) and when the browser is finally able to begin processing event handlers in response to that interaction.
To put it simply, FID is the interval between when you click or tap on something, such as a connection or a button, and when the browser reacts to your action and begins processing it.
First Input Delay is measured in milliseconds (ms).
The activities that are counted as user encounters in FID must be discrete (finite). This metric cannot accurately quantify continuous forms of user activity, such as zooming or scrolling the screen. They always do not run on the browser’s main thread and are subject to various constraints.

Follow More Articles

Contact Us

FID only tests the first interaction.

FID is all about first impressions. The first time a user communicates with your website has a significant impact on their understanding and interpretation of your web performance.
Furthermore, the majority of blocking of the browser’s main thread happens in the first moments of a page’s life cycle – as vital resources are being loaded. First Input Delay is a measure that will help you fix this and ensure that the loading of certain vital services does not make the website feel clunky and unresponsive.

FID measures input delay rather than processing.

FID does not monitor the actual processing or modification of the website as a result of the interaction. That’s because removing the event controller from the task associated with the event would make it easier for developers to play FID.

3. How does First Input Delay vary from Time to Interactive?

Time to Interactive is a useful performance metric that has been around for a while which can seem to be somewhat close to First Input Delay. Time to Interactive (TTI) is a metric that calculates how long it takes for a website to become completely interactive. It is registered when usable content has already been rendered on the website (as determined by First Contentful Paint), event handlers are registered for the majority of page elements, and user interactions are processed within 50ms.
First Input Delay is unique in that it can detect user input that occurs before the website becomes completely interactive. For example, a user can click on a link that occurs before most page elements’ event handlers are registered. In contrast to Time to Interactive, First Input Delay helps you to catch such early, crucial experiences.
In Lighthouse, you can see Time to Interactive.

4. Why is First Input Delay a reasonable metric to concentrate on?

Since it is strictly a Real User Metric, First Input Delay is one of the most exciting web performance metrics. It cannot be replicated in a lab test; it must be calculated by user interaction. FID is concerned with the real experience of a person who visits your website.
For that reason alone, it’s an excellent statistic to monitor and optimize, as it determines the User Experience on your website. In terms of SEO, it is now official the First Input Delay is about to begin shaping the website’s rankings.
First Input Delay is one of three performance metrics that Google wants to promote for its Core Web Vitals program, along with Cumulative Layout Shift and Largest Contentful Paint. The parameter that measures a website’s responsiveness is First Input Delay, while CLS tracks visual consistency and LCP tracks loading speed.
When the Page Experience update goes online, Google hopes to incorporate Core Web Vitals into its ranking algorithm. In other words, there are several reasons to prioritize First Input Delay optimization on your website.

5. What is a good FID score?

The user’s perception of the system responding instantly is limited to around 0.1 seconds. As a result, it’s a smart idea to keep the FID under 100ms.
This is mirrored in FID thresholds in PageSpeed Insights:
  • A FID of less than 100 milliseconds is considered fine.
  • A FID of 100-300ms needs improvement.
  • FID greater than 300ms is considered bad.
The 75th percentile of page loads, segmented between mobile and desktop computers, is a reasonable threshold to calculate and ensure you’re meeting this target for the majority of your customers.

6. FID in detail

As developers who write code that reacts to events, we always expect that our code will be executed immediately—as soon as the incident occurs. But, as consumers, we’ve all had the opposite experience: we’ve loaded a web page on our tablet, attempted to connect with it, and then been disappointed that nothing happened.
In general, input delay (also known as input latency) occurs when the browser’s main thread is busy doing something else and therefore cannot (yet) react to the user. One common explanation for this is that the browser is busy parsing and running a massive JavaScript file that your app has loaded. It can’t run any event listeners when it’s doing that because the JavaScript it’s loading may tell it to do something else.
Take a look at the following timeline for a standard web page load:
The above visualisation depicts a page making a lot of network requests for services (most certainly CSS and JS files), which are then handled on the main thread after they’ve been downloaded. As a consequence, the key thread is temporarily busy, as shown by the beige-colored work blocks.
Long first input delays are common between First Contentful Paint (FCP) and Time to Interactive (TTI) since the website has rendered some of its content but isn’t yet consistently interactive. FCP and TTI have been applied to the timeline to demonstrate how this can occur:
You may have found that there is a significant period of time (including three long tasks) between FCP and TTI; if a user attempts to communicate with the page during that time (e.g., by clicking on a link), there may be a pause between when the click is received and when the main thread is able to react.
You may have found that there is a significant period of time (including three long tasks) between FCP and TTI; if a user attempts to communicate with the page during that time (e.g., by clicking on a link), there may be a pause between when the click is received and when the main thread is able to react.
Since the input arrives when the browser is in the middle of a task, it must wait until the task is over before responding to the information. The time it must wait is the FID value for this user on this page.

7. What if an interaction lacks an event listener?

FID calculates the time elapsed between the receipt of an input occurrence and the next idle state of the main thread. This means the FID is calculated even though no event listener is recorded. The explanation for this is that certain user experiences do not necessitate the use of an event handler but do necessitate the main thread to be inactive in order to function.
For eg, before reacting to user experiences, all of the following HTML elements must wait for in-progress tasks on the main thread to complete:
  • Text fields, checkboxes, and radio buttons <input>,<textarea>
  • Select dropdowns <select>
  • links <a>

8. Why only consider the first input?

Although a delay from any input will result in a poor user experience, we specifically suggest calculating the first input delay for a few reasons:
The first input delay would be the user’s first experience of your site’s responsiveness, and first impressions are crucial in forming an overall impression of a site’s quality and reliability.
The most serious interactivity problems on the site today arise during page load. As a result, we conclude that initially concentrating on enhancing the site’s first user engagement would have the biggest effect on improving the web’s overall interactivity.
The solutions suggested for how sites can address high first-input delays (code-splitting, loading fewer JavaScript upfront, etc.) are not always the same solutions for solving slow input delays after page load. We’ll be able to offer more detailed performance guidelines to web developers if we separate these measurements.

9. What counts as a first input?

FID is a metric that calculates the responsiveness of a page during load. As a result, it only considers feedback events from discrete acts such as clicks, touches, and key presses.
Some interactions, such as scrolling and zooming, are constant activities with entirely different performance constraints (also, browsers are often able to hide their latency by running them on a separate thread).
To put it another way, FID relies on R (responsiveness) in the RAIL performance model, while scrolling and zooming are more relevant to A (animation) and should be measured separately.

10. What if a user never interacts with your site?

Not all visitors to your site will interact with it every time they visit. Furthermore, not all interactions are important to FID (as mentioned in the previous section). Furthermore, some users’ first encounters will occur during difficult periods (when the main thread is busy for a prolonged amount of time), and others will occur during good times (when the main thread is completely idle).
This means that some people will have no FID values, while others will have medium FID values and sometimes even others will have high FID values.
How you monitor, report on, and analyze FID would most likely vary significantly from how you track, report on, and analyze other metrics. The following segment discusses how to do this effectively.

11. Why only consider the input delay?

FID, as previously said, only tests the “delay” in event processing. It doesn’t monitor either the event processing time or the time it takes the browser to refresh the UI after event handlers have been executed.
Even though this time is important to the user and has an impact on the experience, it isn’t used in this metric since using it might encourage developers to add workarounds that would make the experience worse—for example, they might wrap their event handler logic in an asynchronous callback (via setTimeout() or requestAnimationFrame()) to isolate it from the task associated with the metric. As a result, the metric score would increase, but the consumer would expect a slower response.
However, although FID only tracks the “delay” component of event latency, developers can use the Event Timing API to monitor the whole event lifecycle. For more details, see the custom metrics guide.

12. How to measure FID

Tools

The following tools can show you your FID gathered in the field:
  • 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

Using JavaScript to measure FID

You may also use JavaScript to calculate FID on your website.
There are two options for doing so:
  • Using the JavaScript library web-vitals. To get the FID printed in the console, add the following code to your page:
    import {getFID} from ‘web-vitals’;
    getFID(console.log);
  • Manually inserting a PerformanceObserver to log feedback.
If you don’t want to import the web-vitals library, you can manually watch FID using the Event Timing API.

Follow More Articles

Contact Us

May 29th, 2021|
This website or its third party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy . By tapping on "I accept" you agree to the use of cookies.