Measuring First Input Delay
First Input Delay
Delays to the first user input are caused when the browser is busy downloading assets, parsing scripts, or executing blocking operations. The page appears unresponsive when the user interacts with a busy browser by either clicking or typing. FID measures this unresponsive time, but does not include the time taken in the event handlers themselves.
First Input Delay isn’t just an important measure of user experience. It and other Core Web Vital metrics impact SEO because Google will soon consider them when ranking search results.
First Input Delay will be different for every application, but Google has provided basic guidance on acceptable FID times:
What Causes First Input Delay?
Measuring First Input Delay With The Event Timing API
We can test the API’s behavior with a little code:
buffered: true option returns the entry even if it occurred before the PerformanceObserver was configured.
First Input Delay Quirks And Gotchas
While the measurement itself is straightforward, FID measurements have several quirks that you should be aware of.
1. First Input Delay Measurements Don’t Always Occur
Not every page view results in a FID entry. If the user never interacts with the page, no first input entry will be recorded.
2. User Input Includes Clicks On Non-Interactive Elements
The First Input Delay measurement is triggered even when the user clicks non-interactive elements like the page background. This causes unintentional or frustrated user actions to be reflected in the FID measurements:
3. First Input Delay Measurements Are Highly Variable
The same page can return a wide range of FID values between different page loads and users. User interaction can happen at any time. This user variability is reflected in FID values because of the varying states of page readiness:
4. Don’t Measure Pages Loaded In The Background!
First Input Delay should not be measured when the page is loaded in a background tab. The measurement is of questionable value because the first interaction happens long after the tab is loaded. An additional check prevents measurement of background tabs:
5. Event Timing API Feature Detection
Not all browsers support the Event Timing API. Try/catch is the only reliable way to detect the feature because some browsers throw an exception when the API is used:
First Input Delay helps you understand how real users perceive the performance of page interactions. Gain a more complete understanding of your frontend performance by measuring the other two Web Vitals metrics: Largest Contentful Paint and Cumulative Layout Shift.
Looking for more? Check out the Definitive Guide to Measuring Web Performance.