First Input Delay (FID): what is it?
First Input Delay (FID) is a user-centric metric that measures responsiveness following an interaction on a web page. It quantifies the wait users have when a page is unresponsive. Thus, a low FID indicates that the page is usable quickly.
Making a good impression is important on a first meeting, and the same goes for a website!
This first impression is crucial because it can lead to loyalty or, on the contrary, the loss of a potential customer who will never come back. But how do you make a good impression, and how do you measure it?
On a website, this can take different forms: design and visual appearance (UI), but also responsiveness and speed ( UX ).
While it’s difficult to measure how much users like a site’s interface and design with web APIs, measuring speed and responsiveness is fortunately possible.
When it comes to display, the perception of speed can be assessed using First Contentful Paint (FCP is a Real User Monitoring metric; on Synthetic Monitoring tools, its equivalent is Start Render ). But the speed at which your site can render pixels on the screen is only one facet of UX. Interactivity is just as important!
The First Input Delay (FID) allows you to evaluate the first impression of Internet users regarding the interactivity and responsiveness of your website.
What is First Input Delay? Definition.
FID measures the time between when a user first interacts with a page (i.e. when they click a link, press a button, or use a custom JavaScript control…) and when the browser is actually able to respond to that interaction .
What is a good FID score?
To provide a good user experience, a website should have a FID score of less than 100 milliseconds according to Google’s recommendations . To ensure you achieve this goal for most of your users, you can base your search on the 75th percentile of your page load times, for both mobile and desktop devices .
Understanding First Input Delay
A developer usually assumes that the code will be executed immediately as soon as the triggering event occurs. But as users, we often experience the opposite: after loading a web page on our phone, we try to interact and get frustrated if nothing happens.
This latency occurs because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user. The most common explanation is that the browser is parsing and executing a large JavaScript file (this is even more true on low-end mobiles !). The JavaScript then takes up all its attention and it doesn’t do anything else at the same time.
Here is the typical timeline of a web page loading:
The visualization above shows a page making requests for network resources (probably CSS and JS files) and once these resources are finished downloading, they are processed on the main thread .
This results in periods where the main thread is temporarily busy, which is indicated by yellow task blocks.
Long FIDs typically occur between First Contentful Paint (FCP) and Time To Interactive (TTI) because the page is displaying some of its content but is not yet sustainably interactive. To illustrate this process, FCP and TTI have been added to the timeline
You noticed some delay (including 3 long tasks) between FCP and TTI. If a user tries to interact with the page during this time (e.g. clicking a link), there will be a delay between the click and the main thread being able to respond.
Consider what would happen if a user tried to interact with the page at the beginning of the longest task:
Since the input occurs while the browser is performing a task, it must wait for that task to complete before responding – and this wait time is the FID.
NB: In this example, the user just interacted with the page at the beginning of the main thread ‘s busiest period . If the user had interacted with the page just a moment earlier (during the idle period), the browser might have responded immediately. This variance in input delay underscores the importance of examining the distribution of FID values when reporting on this metric. We’ll come back to this later in the section on analyzing and reporting on FID data.
What if an interaction has no event listener ?
FID measures the difference between receiving an input event and the next time the main thread is able to interact. This means that FID is measured even in cases where an event listener has not been registered. This is because many interactions do not require an event listener , but they do require the main thread to be idle to function.
For example, all of the following native HTML elements must wait for ongoing tasks on the main thread to complete before responding to user interactions:
- Text fields, check boxes, radio buttons ( <input> , <textarea> )
- Drop-down menu ( <select> )
- Links ( <a> )
FID: why only consider the first input ?
While a delay in any input can result in a poor user experience, Google recommends measuring First Input Delay as a priority for several reasons:
- FID represents a user’s first impression of a site’s responsiveness, and first impressions are critical in shaping the overall impression of a site’s quality and reliability.
- The biggest interactivity issues seen on the web today occur during page load, so focusing on improving the first interaction will have the biggest impact on improving overall interactivity.
- The recommended solutions for improving First Input Delay ( code splitting , reducing preloaded JavaScript , etc.) are not necessarily the same as those needed to fix slow inputs after the page loads. Separating these measures allows for specific recommendations for each case.
FID: what input is taken into account?
FID is a metric that measures how responsive a page is while loading. As such, it focuses only on events related to actions such as clicks, keystrokes, and key presses.
Other interactions, like scrolling and zooming, are continuous actions and have completely different performance constraints (so browsers are often able to hide their latency by running them on a separate thread ).
In other words, FID focuses on R (Responsiveness) in the RAIL performance model , while scrolling and zooming are more related to A (Animation), and their performance should be evaluated separately.
How to measure FID without interaction?
Not all users interact with your site on every visit, and not all interactions are relevant to FID (as mentioned in the previous section). Additionally, some users’ first interactions may come at inopportune times (when the main thread is busy for an extended period of time), and some users’ first interactions may sometimes come at the right times (when the main thread is completely idle).
This means that some users will have no FID values, some users will have low FID values, and some users will likely have high FID values. So how do you figure it out?
This variety of scenarios makes FID tracking, reporting, and analysis different from other web performance metrics, and here’s how to do it.
How to measure FID
FID can only be measured through Real User Monitoring (RUM) because it requires a real user to interact with the page. You can measure FID with the following techniques.
Field tools for measuring FID (RUM)
- Chrome User Experience Report
- PageSpeed Insights
- Search Console (Core Web Vitals report)
- Firebase Performance Monitoring (beta)
NB: The equivalent of FID on Synthetic Monitoring tools is Total Blocking Time (TBT). It also captures issues that affect interactivity. TBT optimization recommendations should also improve FID for your users.
Measuring FID in JavaScript
The easiest way to measure FID (like all other Field metrics of Web Vitals ) is to use web-vitals JavaScript library which simplifies the measurement into a single function:
import {getFID} from 'web-vitals';
// Measure and log the current FID value,
// any time it's ready to be reported.
getFID(console.log);
Pour mesurer manuellement le FID, vous pouvez utiliser Event Timing API. L’exemple suivant montre comment créer un PerformanceObserver qui relève les occurrences first-input, calcule le FID, et logue les valeurs dans la console :
// Keep track of whether (and when) the page was first hidden, see:
// https://github.com/w3c/page-visibility/issues/29
// NOTE: ideally this check would be performed in the document <head>
// to avoid cases where the visibility state changes before this code runs.
let firstHiddenTime = document.visibilityState === 'hidden' ? 0 : Infinity;
document.addEventListener('visibilitychange', (event) => {
firstHiddenTime = Math.min(firstHiddenTime, event.timeStamp);
}, {once: true});
// Sends the passed data to an analytics endpoint. This code
// uses `/analytics`; you can replace it with your own URL.
function sendToAnalytics(data) {
const body = JSON.stringify(data);
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
// Use a try/catch instead of feature detecting `first-input`
// support, since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
function onFirstInputEntry(entry) {
// Only report FID if the page wasn't hidden prior to
// the entry being dispatched. This typically happens when a
// page is loaded in a background tab.
if (entry.startTime < firstHiddenTime) {
const fid = entry.processingStart - entry.startTime;
// Report the FID value to an analytics endpoint.
sendToAnalytics({fid});
}
}
// Create a PerformanceObserver that calls `onFirstInputEntry` for each entry.
const po = new PerformanceObserver((entryList) => {
entryList.getEntries().forEach(onFirstInputEntry);
});
// Observe entries of type `first-input`, including buffered entries,
// i.e. entries that occurred before calling `observe()` below.
po.observe({
type: 'first-input',
buffered: true,
});
} catch (e) {
// Do nothing if the browser doesn't support this API.
}
LA MESURE DE L’INTERACTIVITÉ AVEC LE FID (DONNÉE FIELD) ET LE TBT (DONNÉE LAB)
Le FID nécessite une interaction réelle de l’utilisateur
La métrique FID mesure la réactivité d’une page aux interactions des utilisateurs, au moment où ceux-ci choisissent effectivement d’interagir avec elle.
La deuxième partie de cette phrase est essentielle car les tests avec des données Lab – même ceux qui observent le comportement de l’utilisateur – ne peuvent pas prédire avec précision le moment où les utilisateurs choisiront d’interagir avec une page, et ne peuvent donc pas mesurer avec précision le FID.
Le TBT et le TTI ne tiennent pas compte du comportement de l’utilisateur
Les mesures de laboratoire telles que le Total Blocking Time (TBT) et le Time To Interactive (TTI) aident à diagnostiquer les problèmes de FID car elles quantifient le degré de blocage du fil principal pendant le chargement de la page.
L’idée est que les pages contenant beaucoup de JavaScript synchrone ou d’autres tâches de rendu importantes sont plus susceptibles d’avoir un fil principal bloqué lorsque l’utilisateur interagit pour la première fois. Cependant, si les utilisateurs attendent pour interagir avec la page que le JavaScript ait fini de s’exécuter, le FID peut être très faible.
Le moment où les utilisateurs choisissent d’interagir avec une page dépend largement de son aspect interactif ou non, ce qui ne peut être mesuré avec TBT ou TTI.
Le TBT et le TTI ne tiennent pas compte du délai lié au tapotement sur un écran mobile
Si un site n’est pas optimisé pour l’affichage mobile, les navigateurs ajouteront un délai de 300 ms après toute pression avant d’exécuter les gestionnaires d’événements. En effet, ils doivent déterminer si l’utilisateur essaie d’effectuer un double tapotement pour zoomer avant de pouvoir déclencher les événements souris ou clic.
Ce délai est pris en compte dans le FID d’une page car il contribue à la latence réelle à laquelle les utilisateurs sont confrontés. Mais comme ce délai n’est pas techniquement une tâche longue (Long Task), il n’affecte pas le TBT ou le TTI d’une page. Cela signifie qu’une page peut avoir un mauvais FID malgré de très bons scores TBT et TTI.
NB : Pour éviter le problème de Tap Delay sur une page, spécifiez toujours un viewport mobile.
Les effets de l’état de la mémoire cache et du bfcache sur le FID
De la même manière qu’une mise en cache appropriée peut améliorer le LCP pour les données Lab, elle peut également améliorer le FID.
Dans le monde réel, un utilisateur peut avoir le JavaScript d’un site déjà dans son cache, de sorte que son traitement peut prendre moins de temps et entraîner des délais moins importants.
Il en va de même pour les pages restaurées à partir du bfcache. Dans ce cas, le JavaScript est restauré à partir de la mémoire, de sorte que le temps de traitement peut être faible, voire nul.
Field ou Lab : quelles métriques prioriser pour optimiser la réactivité d’une page ?
En règle générale, les données de terrain sont celles que vous devez utiliser pour prioriser vos efforts. Puisque les données de terrain représentent ce que vivent les utilisateurs réels, c’est le moyen le plus précis de comprendre réellement ce qui pose problème à vos utilisateurs et ce qui doit être amélioré.
En revanche, si vos données de terrain montrent de bons résultats dans l’ensemble, mais que vos données de laboratoire suggèrent qu’il y a encore de la place pour des améliorations, cela vaut la peine de creuser pour comprendre quelles optimisations supplémentaires peuvent être apportées.
Analyse et génération de rapports sur les données FID
Etant donné que les valeurs de FID varient, il est essentiel que lors de la génération de rapports sur cette métrique, vous examiniez la distribution des valeurs et vous concentriez sur les centiles supérieurs.
Bien que le choix du centile pour tous les Core Web Vitals soit le 75ème, pour le FID en particulier, Google recommande vivement de regarder les 95ème à 99ème centiles (que ce soit sur mobile ou desktop), car ceux-ci correspondront aux premières expériences particulièrement mauvaises que les utilisateurs auront avec votre site. Vous verrez ainsi les domaines qui nécessitent le plus d’amélioration.
Comment améliorer le First Input Delay
Pour savoir comment améliorer le FID, vous pouvez lancer un audit de performance Lighthouse et prendre note des recommandations de l’audit (voici quelques suggestions pour appliquer correctement les recommandations de PageSpeed Insight).
Alors que le FID est une métrique Field (et Lighthouse est un outil de mesure Lab), les conseils pour améliorer le FID sont sensiblement les mêmes que pour améliorer le Total Blocking Time (TBT), comme nous l’avons évoqué plus haut.
Enfin, vous pouvez aussi améliorer votre FID grâce aux techniques suivantes (en anglais) :
- Réduisez l’impact des Third Parties sur votre code
- Réduisez le temps d’exécution du JavaScript
- Minimisez le travail du Main Thread
- Réduisez le nombre de requêtes et la taille des échanges
Suivre les évolutions du First Input Delay
Google corrige et fait évoluer les API utilisées pour mesurer les métriques, ainsi que la définition des métriques elles-mêmes. Ces modifications peuvent entraîner des améliorations ou des régressions dans vos rapports et tableaux de bord internes. Pour vous aider à suivre ces évolutions, les modifications sont consignées dans ce Changelog.
Pour approfondir le sujet en vidéo, le replay de notre webinaire dédié au FID est ici :
Vous souhaitez savoir comment automatiser les optimisations
qui vous permettront d’améliorer votre FID et l’ensemble de vos Core Web Vitals ?
