This post is part of the Core Web Vitals Guide series.
Maxi Becher
FID, or "First Input Delay" indicates how much time elapses between the first interaction (e.g. click on a link) with the page and the resulting browser reaction.
An example:
A page is still under construction when the desired button is already displayed. A website user then clicks on it and nothing happens because the page was only partially loaded and the button is not yet responding.
The problem: input delay (or input latency).
Classification of the results
| Classification | Response Time/Delay |
|---|---|
| 🟢 good | < 100ms |
| 🟡 needs improvement | 100 to 300ms |
| 🔴 bad, need for action | > 300ms |
What is assessed
FID captures direct user input such as clicks, tabs, and keystrokes.
FID can therefore also intercept cases in which no event listener was registered.
This corresponds to the
R(responsiveness) of the RAIL Performance Model.
Not taken into account:
- Scrolling
- Zoom
- And ongoing actions (click again etc.)
This corresponds to the
A(animation) of the RAIL Performance Models.
Opportunities for optimization
The problems mostly arise between First Contentful Paint and Time To Interactive (TTI).
And this is where we can start with a solution.
To optimize FID, it also helps to evaluate the Total Blocking Time (TBT);
While using other metrics, the TBT Optimization tips are helpful for FID improvements.
Split long tasks
-
Long tasks are phases in which JS is executed, which often leads to an inability to interact with the page.
-
According to Google, when the main thread is blocked for more than 50 milliseconds.
Prefer interactions
- Prioritize loading of items to interact with.
Deploy service workers
- Web Worker allows complex JS files to be executed in a separate thread and not block the main thread.
Reduce JS Runtime
- Evaluate scripts, prioritize them and reload those that aren't essential.
- Reduce the effect of third party software.
More tips
Google itself lists other tips for optimizing FID: see web.dev/optimize-FID