Excellent software and practical tutorials
We all know how important it is to make a good first impression. Not only is this important when meeting new people, but it’s also important when shaping experiences online.
Online, a good first impression can mean the difference between becoming a loyal user or never coming back. The question is, what makes a good experience, and how do you measure that impression?
On the Internet, first impressions can take many different forms. We form first impressions on a site’s design and visual appeal, but we also form first impressions on its speed and responsiveness.
While it’s difficult to measure how much users like a website’s design through a web API, a web API can easily measure website speed and responsiveness!
Users’ first impression of your website’s loading speed can be determined byFirst Contentful Paint (FCP)Measure it. But how fast your site can draw pixels on the screen is only part of the story, just as important is how responsive your site is when a user tries to interact with those pixels!
First Input Delay (FID) metrics help measure your users’ first impression of your website’s interactivity and responsiveness.
What is FID?
FID measures the time from the time a user first interacts with a page (such as when they click a link, tap a button, or use a custom control driven by JavaScript) until the browser responds to the interaction and is actually able to start processing event handlers.
What is a good FID score?
To provide a good user experience, websites should strive to set the first input delay to100 msor less. To ensure that you are hitting the recommended target for the majority of your users’ visits, a good measurement threshold is75th percentile, and this threshold applies to both mobile and desktop devices.
FID Details
As developers writing code in response to events, we often assume that our code will run immediately when the event occurs. But as users, we have all faced the opposite situation frequently, when we load a web page on our phone, try to interact with the page, and then get frustrated because the page does not respond at all.
Generally speaking, input delay (also known as input lag) occurs because the browser's main thread is busy doing other work and therefore can't respond to the user (yet). One common reason this can happen is that the browser is busy parsing and executing a large JavaScript file loaded by your application. During this process, the browser can't run any event listeners because the JavaScript being loaded might keep the browser busy doing other work.
Consider this typical web page loading timeline:
The visualization above shows a page that is making several network requests to fetch resources (mostly CSS and JS files), which are then processed on the main thread after being downloaded.
This causes the main thread to be busy periodically (indicated by beige in the figure).Taskpiece).
Long first input delays usually occur whenFirst Contentful Paint (FCP)andTime to Interactive (TTI)Because during this period, the page has rendered some content, but the interactivity is not yet reliable. To illustrate why this happens, we added FCP and TTI to the timeline:
You may have noticed that there is quite a long period (including threeLong tasks), if the user tries to interact with the page (such as clicking a link) during this time, there will be a delay from the time the browser receives the click until the main thread is able to respond.
Look what happens if the user tries to interact with the page at the very beginning of the longest task:
Because the input occurs while the browser is in the middle of a task, the browser must wait until the task is complete before responding to the input. The time the browser must wait is the FID value that the user experiences on the page.
In this example, the user interacted with the page right as the main thread was entering its busiest period. If the user had interacted with the page slightly earlier (during an idle period), the browser would have responded immediately. This difference in input latency highlights the importance of looking at the distribution of FID values when reporting metrics. You can read more about this in the section below about analyzing and reporting FID data.
What if the interaction has no event listener?
FID measures the difference between the time an input event is received and the next time the main thread is idle. This means that FID is measured even if no event listeners have been registered. This is because many user interactions do not require event listeners to execute, butmustThe main thread needs to be in an idle period.
For example, all of the following HTML elements need to wait for ongoing tasks on the main thread to finish running before responding to user interactions:
- Text fields, checkboxes, and radio buttons (input, textarea)
- Drop-down selection list (select)
- Link(a)
Why only first input is considered?
While any input delay can result in a poor user experience, we primarily recommend measuring First Input Delay for the following reasons:
- First Input Delay will be the user's first impression of your site's responsiveness, and first impressions are critical in shaping our overall impression of a site's quality and reliability.
- The biggest interactivity issues we see on the web today occur during page load. Therefore, we believe that focusing first on improving the first user interaction with a site will have the greatest impact on improving the overall interactivity of the web.
- The solutions we recommend sites take for high first input delay (code splitting, reducing the amount of JavaScript preloaded, etc.) are not necessarily the same as the solutions for slow input delay after the page loads. By separating these metrics, we will be able to provide more precise performance guidance to web developers.
What counts as first-time input?
FID is a metric that measures responsiveness during page load. Therefore, FID only focuses on input events corresponding to discrete actions, such as clicks, taps, and keypresses.
Other interactions like scrolling and zooming are sequential operations with completely different performance constraints (and browsers are often able to hide latency by performing these operations on a separate thread).
In other words, FID focuses onRAIL Performance ModelIn the performance evaluation, scrolling and zooming are more related to A (animation), so the performance quality of these operations should be evaluated separately.
What if the user never interacts with your website?
Not all users interact with your site every time they visit it. And not all interactions correlate with FID (as discussed in the previous section). In addition, some users’ first interactions will fall during unfavorable time periods (when the main thread is busy for a long time), while other users’ first interactions will fall during favorable time periods (when the main thread is completely idle).
This means that some users will have no FID value, some will have a low FID value, and some may have a high FID value.
How you track, report, and analyze FID may be very different from the other metrics you are used to. The next section describes best practices.
Why only consider input delay?
As mentioned above, FID only measures the "latency" within the event handling process. FID does not measure the time taken for the event handling itself, nor does it measure the time it takes for the browser to update the user interface after running the event handler.
Although these times are very important to users,reallyThis will affect the user experience, but these times are not included in this indicator because such practices may encourage developers to add workarounds and thus make the experience worse. What this means is that developers can encapsulate the event handler logic in an asynchronous callback (via setTimeout() or requestAnimationFrame()) to separate the logic from the task associated with the event. The final result can improve the indicator score, but it will make the user perceive a slower response speed.
However, while FID only measures the "latency" portion of event latency, developers who want to track more of the event lifecycle can useEvent Timing APIFor more details, seeCustom Indicatorsrelevant guidance.
How to measure FID
FID is aactualFID is a metric that requires real users to interact with your page. You can use the following tools to measure FID.
Measurement tools
- Chrome User Experience Report
- PageSpeed Insights Web Page Speed Measurement Tool
- Search Console (Core Web Metrics Report)
- web-vitals JavaScript library
Measuring FID in JavaScript
To measure FID in JavaScript, you can useEvent Timing APIThe following example shows how to create aPerformanceObserverCome listenfirst-inputentries and logged in the console:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
const delay = entry.processingStart - entry.startTime;
console.log('FID candidate:', delay, entry);
}
}).observe({type: 'first-input', buffered: true});
In the example above, the latency of the first-input entry is measured by taking the difference between the entry's startTime and processingStart timestamps. In most cases, this difference is the FID value, however, not all first-input entries can be used to measure FID.
The following sections list the differences between what the API reports and how the metrics are calculated.
Differences between indicators and APIs
- The API will dispatch first-input entries for pages loaded in background tabs, but these pages should be ignored when calculating FID.
- If the page moves to the background before first input occurs, the API will also dispatch first-input entries, but these pages should still be ignored when calculating FID (input is only considered if the page is always in the foreground).
- When the page passesRoundtrip CacheWhen resuming, the API does not report the first-input entry, but FID should be measured in these cases because this is multiple different page visits for the user.
- The API does not report inputs in iframes, but you should account for them to properly measure FID. Child frames can use the API to report the first-input entries of these inputs to the parent frame for aggregation.
Instead of having to remember all these nuances, developers can useweb-vitals JavaScript libraryto measure FID, the library handles these differences itself (where possible):
import {getFID} from 'web-vitals';
// Measure and record immediately when FID is available.
getFID(console.log);
You can refer to the source code of getFID for a complete example of how to measure FID in JavaScript.
Analyze and report FID data
Because of the expected variation in FID values, it is critical that you look at the distribution of values when reporting FID and focus on the higher percentiles.
Although all core web metrics thresholdsPreferred percentileis the 75th percentile, but specifically for FID, we still strongly recommend setting your threshold at the 95th-99th percentile because these percentiles correspond to particularly bad first experiences users have on your site, and thus will tell you where you need the most improvement.
This should be done even if you segment your reports by device category or type. For example, if you report on desktop and mobile separately, the desktop FID value you should be most concerned about is the 95th-99th percentile of desktop users, and the mobile FID value you should be most concerned about is the 95th-99th percentile of mobile users.
How to Improve FID
To learn how to improve FID for a specific site, you can run a Lighthouse performance audit and look at the specific options the audit recommends.Chance.
Although FID is a practical indicator (and Lighthouse is a laboratory indicator tool), the guidance for improving FID is similar to improvingTotal blocking time (TBT)This laboratory indicator has the same guiding direction.
For more information on how to improve FID, seeOptimizing FIDFor further guidance on other individual performance tips that can improve FID, see:
