Philip Walton

We all know how important it is to make a good first impression. It's importantwhen meeting new people, and it's also important when building experiences onthe web.

On the web, a good first impression can make the difference between someonebecoming a loyal user or them leaving and never coming back. The question is,what makes for a good impression, and how do you measure what kind of impressionyou're likely making on your users?

On the web, first impressions can take a lot of different forms—we havefirst impressions of a site's design and visual appeal as well as firstimpressions of its speed and responsiveness.

While it is hard to measure how much users like a site's design with web APIs,measuring its speed and responsiveness is not!

The first impression users have of how fast your site loads can be measured withFirst Contentful Paint (FCP). But how fast your site can paint pixelsto the screen is just part of the story. Equally important is how responsiveyour site is when users try to interact with those pixels!

The First Input Delay (FID) metric helps measure your user's first impression ofyour site's interactivity and responsiveness.

What is FID?

FID measures the time from when a user first interacts with a page (that is, whenthey click a link, tap on a button, or use a custom, JavaScript-powered control)to the time when the browser is actually able to begin processing event handlersin response to that interaction.

What is a good FID score?

To provide a good user experience, sites should strive to have a First InputDelay of100 milliseconds or less. To ensure you're hitting this target formost of your users, a good threshold to measure is the75th percentile ofpage loads, segmented across mobile and desktop devices.

FID in detail

As developers who write code that responds to events, we often assume our codeis 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 onour phone, tried to interact with it, and then been frustrated when nothinghappened.

In general, input delay (a.k.a. input latency) happens because the browser'smain thread is busy doing something else, so it can't (yet) respond to the user.One common reason this might happen is the browser is busy parsing and executinga large JavaScript file loaded by your app. While it's doing that, it can't runany event listeners because the JavaScript it's loading might tell it to dosomething else.

Consider the following timeline of a typical web page load:

The above visualization shows a page that's making a couple of network requestsfor resources (most likely CSS and JS files), and—after those resourcesare finished downloading—they're processed on the main thread.

This results in periods where the main thread is momentarily busy, which isindicated by the beige-coloredtaskblocks.

Long first input delays typically occur betweenFirst Contentful Paint(FCP) andTime to Interactive (TTI) because the page hasrendered some of its content but isn't yet reliably interactive. To illustratehow this can happen, FCP and TTI have been added to the timeline:

You may have noticed that there's a fair amount of time (including threelongtasks) between FCP and TTI, if a user tries tointeract with the page during that time (for example, by clicking on a link), there will be adelay between when the click is received and when the main thread is able torespond.

Consider what would happen if a user tried to interact with the page near thebeginning of the longest task:

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. Thetime it must wait is the FID value for this user on this page.

To put this another way, FID focuses on the R (responsiveness) in theRAILperformancemodel, whereasscrolling and zooming are more related to A (animation), and their performancequalities should be evaluated separately.

What if a user never interacts with your site?

Not all users will interact with your site every time they visit. And not allinteractions are relevant to FID (as mentioned in the previous section). Inaddition, some user's first interactions will be at bad times (when the mainthread is busy for an extended period of time), and some user's firstinteractions will be at good times (when the main thread is completely idle).

This means some users will have no FID values, some users will have low FIDvalues, and some users will probably have high FID values.

How you track, report on, and analyze FID will probably be quite a bit differentfrom other metrics you may be used to. The next section explains how best to dothis.

Why only consider the input delay?

As mentioned above, FID only measures the "delay" in event processing. It doesnot measure the total event processing duration itself, nor the time it takesthe browser to update the UI after running event handlers.

Even though this time is important to the user anddoes affect the experience,it's not included in this metric because doing so could incentivize developersto add workarounds that actually make the experience worse—that is, theycould wrap their event handler logic in an asynchronous callback (viasetTimeout() orrequestAnimationFrame()) in order to separate it from thetask associated with the event. The result would be an improvement in the metricscore but a slower response as perceived by the user.

However, while FID only measure the "delay" portion of event latency, developerswho want to track more of the event lifecycle can do so using theEvent TimingAPI. See the guide oncustommetrics for more details.

How to measure FID

FID is a metric that can only be measuredin thefield, as it requires a realuser to interact with your page. You can measure FID with the following tools.

Field tools

• Chrome User ExperienceReport
• PageSpeed Insights
• Search Console (Core Web Vitalsreport)
• web-vitals JavaScript library

Measure FID in JavaScript

To measure FID in JavaScript, you can use theEvent TimingAPI. The following example shows how tocreate aPerformanceObserverthat listens forfirst-inputentries and logs them to the console:

newPerformanceObserver((entryList)=>{for(constentryofentryList.getEntries()){constdelay=entry.processingStart-entry.startTime;console.log('FID candidate:',delay,entry);}}).observe({type:'first-input',buffered:true});

• The API will dispatchfirst-input entries for pages loadedin a background tab but those pages should be ignored when calculating FID.
• The API will also dispatchfirst-input entries if the page was backgroundedprior to the first input occurring, but those pages should also be ignoredwhen calculating FID (inputs are only considered if the page was in theforeground the entire time).
• The API does not reportfirst-input entries when the page is restored fromtheback/forward cache, but FID shouldbe measured in these cases since users experience them as distinct pagevisits.
• The API does not report inputs that occur within iframes but the metric doesas they are part of the user experience of the page. This canshow as a difference between CrUX and RUM.To properly measure FID you should consider them. Sub-frames can use the APIto report theirfirst-input entries to the parent frame for aggregation.

Whilechoice ofpercentile for allCore Web Vitals thresholds is the 75th, for FID in particular we still stronglyrecommend looking at the 95th–99th percentiles, as those will correspond to theparticularly bad first experiences users are having with your site. And it willshow you the areas that need the most improvement.

This is true even if you segment your reports by device category or type. Forexample, if you run separate reports for desktop and mobile, the FID value youcare most about on desktop should be the 95th–99th percentile of desktop users,and the FID value you care about most on mobile should be the 95th–99thpercentile of mobile users.

How to improve FID

A full guide onoptimizing FID is available to guide you through techniques to improve this metric.

Changelog

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in thisChangelog.

If you have feedback for these metrics, you can provide it in theweb-vitals-feedback Google group.