First Input Delay (FID)

Philip Walton

Nous savons tous à quel point il est important de faire une bonne première impression. C'est important lorsque vous rencontrez de nouvelles personnes, mais aussi lorsque vous créez des expériences sur le Web.

Sur le Web, une bonne première impression peut faire la différence entre un utilisateur fidèle et un utilisateur qui partira et ne reviendra jamais. La question est de savoir ce qui fait une bonne impression, et comment mesurer le type d'impression que vous êtes susceptible de faire chez vos utilisateurs.

Sur le Web, les premières impressions peuvent prendre de nombreuses formes : nous avons les premières impressions de la conception et de l'attrait visuel d'un site, ainsi que les premières impressions de sa vitesse et de sa réactivité.

Bien qu'il soit difficile de mesurer dans quelle mesure les utilisateurs aiment la conception d'un site avec des API Web, il est facile de mesurer sa vitesse et sa réactivité.

La première impression que les utilisateurs ont de la vitesse de chargement de votre site peut être mesurée avec First Contentful Paint (FCP). Mais la vitesse à laquelle votre site peut peindre des pixels à l'écran n'est qu'une partie de l'histoire. La réactivité de votre site est tout aussi importante lorsque les utilisateurs tentent d'interagir avec ces pixels.

La métrique FID (First Input Delay) permet de mesurer la première impression de l'utilisateur sur l'interactivité et la réactivité de votre site.

Qu'est-ce que le FID ?

Le FID mesure le délai entre le moment où un utilisateur interagit pour la première fois avec une page (c'est-à-dire lorsqu'il clique sur un lien, appuie sur un bouton ou utilise une commande JavaScript personnalisée) et le moment où le navigateur peut réellement commencer à traiter les gestionnaires d'événements en réponse à cette interaction.

Quel est un bon score FID ?

Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer d'avoir un délai de première entrée de 100 millisecondes ou moins. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, un seuil approprié à mesurer est le 75e centile de chargements de pages, segmenté en fonction des appareils mobiles et des ordinateurs de bureau.

FID en détail

En tant que développeurs qui écrivent du code qui répond à des événements, nous supposons souvent que notre code sera exécuté immédiatement, dès que l'événement se produira. Toutefois, en tant qu'utilisateurs, nous avons tous souvent constaté l'inverse : nous avons chargé une page Web sur notre téléphone, essayé d'interagir avec elle, puis avons été frustrés lorsque rien ne s'est produit.

En général, le délai d'entrée (ou latence d'entrée) se produit parce que le thread principal du navigateur est occupé à effectuer une autre tâche. Il ne peut donc pas (encore) répondre à l'utilisateur. Une raison courante pour laquelle cela peut se produire est que le navigateur est occupé à analyser et à exécuter un grand fichier JavaScript chargé par votre application. Pendant ce temps, il ne peut exécuter aucun écouteur d'événement, car le code JavaScript qu'il charge peut lui demander de faire autre chose.

Prenons la chronologie suivante pour le chargement d'une page Web classique:

La visualisation ci-dessus montre une page qui effectue quelques requêtes réseau pour des ressources (probablement des fichiers CSS et JS), qui sont traitées sur le thread principal une fois le téléchargement de ces ressources terminé.

Cela entraîne des périodes où le thread principal est momentanément occupé, ce qui est indiqué par les blocs de tâche beiges.

Les longs délais de première entrée se produisent généralement entre le First Contentful Paint (FCP) et le Time to Interactive (TTI), car la page a affiché une partie de son contenu, mais n'est pas encore interactive de manière fiable. Pour illustrer comment cela peut se produire, le FCP et le TTI ont été ajoutés à la chronologie:

Vous avez peut-être remarqué qu'il y a un certain temps (y compris trois tâches longues) entre le FCP et le TTI. Si un utilisateur tente d'interagir avec la page pendant ce laps de temps (par exemple, en cliquant sur un lien), il y aura un délai entre la réception du clic et le moment où le thread principal pourra répondre.

Réfléchissez à ce qui se passerait si un utilisateur essayait d'interagir avec la page au début de la tâche la plus longue :

Étant donné que la saisie se produit alors que le navigateur est en train d'exécuter une tâche, il doit attendre la fin de la tâche avant de pouvoir y répondre. Le temps d'attente correspond à la valeur FID de cet utilisateur sur cette page.

Que se passe-t-il si une interaction n'a pas d'écouteur d'événements ?

Le FID mesure le delta entre le moment où un événement d'entrée est reçu et le moment où le thread principal est inactif la prochaine fois. Cela signifie que le FID est mesuré même si un écouteur d'événement n'a pas été enregistré. En effet, de nombreuses interactions utilisateur ne nécessitent pas d'écouteur d'événements, mais exigent que le thread principal soit inactif pour pouvoir s'exécuter.

Par exemple, tous les éléments HTML suivants doivent attendre la fin des tâches en cours sur le thread principal avant de répondre aux interactions utilisateur:

• Champs de texte, cases à cocher et boutons d'option (<input>, <textarea>)
• Sélectionner des menus déroulants (<select>)
• associations (<a>)

Pourquoi ne prendre en compte que la première entrée ?

Bien qu'un décalage à partir d'une entrée puisse nuire à l'expérience utilisateur, nous vous recommandons principalement de mesurer le délai de la première entrée pour plusieurs raisons:

• Le premier délai de saisie sera la première impression de l'utilisateur sur la réactivité de votre site. Les premières impressions sont essentielles pour façonner notre impression globale de la qualité et de la fiabilité d'un site.
• Les principaux problèmes d'interactivité que nous constatons aujourd'hui sur le Web se produisent lors du chargement de la page. Par conséquent, nous pensons qu'en se concentrant d'abord sur l'amélioration de la première interaction utilisateur du site, on aura le plus d'impact sur l'amélioration de l'interactivité globale du Web.
• Les solutions recommandées pour résoudre les longs délais d'entrée initiaux (fractionnement du code, chargement de moins de JavaScript au préalable, etc.) ne sont pas nécessairement les mêmes que celles pour résoudre les longs délais d'entrée après le chargement de la page. En séparant ces métriques, nous pourrons fournir des consignes de performances plus spécifiques aux développeurs Web.

Qu'est-ce qui est considéré comme une première entrée ?

Le FID est une métrique qui mesure la réactivité d'une page lors du chargement. Par conséquent, il se concentre uniquement sur les événements d'entrée provenant d'actions discrètes telles que les clics, les appuis et les pressions sur les touches.

D'autres interactions, telles que le défilement et le zoom, sont des actions continues et présentent des contraintes de performances complètement différentes. Par ailleurs, les navigateurs peuvent souvent masquer leur latence en les exécutant sur un thread distinct.

En d'autres termes, le FID se concentre sur le R (réactivité) dans le modèle de performances RAIL, tandis que le défilement et le zoom sont davantage liés à A (animation), et leurs qualités de performances doivent être évaluées séparément.

Que se passe-t-il si un utilisateur n'interagit jamais avec votre site ?

Tous les utilisateurs n'interagiront pas avec votre site à chaque visite. De plus, toutes les interactions ne sont pas pertinentes pour FID (comme indiqué dans la section précédente). De plus, les premières interactions de certains utilisateurs auront lieu à des moments inopportuns (lorsque le thread principal est occupé pendant une longue période) et celles d'autres à des moments opportuns (lorsque le thread principal est complètement inactif).

Cela signifie que certains utilisateurs n'auront aucune valeur FID, d'autres des valeurs FID faibles et d'autres des valeurs FID élevées.

La façon dont vous suivez, analysez et analysez le FID sera probablement très différente des autres métriques auxquelles vous êtes peut-être habitué. La section suivante explique comment procéder.

Pourquoi ne tenir compte que du délai d'entrée ?

Comme indiqué ci-dessus, le FID ne mesure que le "délai" de traitement des événements. Elle ne mesure pas la durée totale du traitement des événements elle-même, ni le temps nécessaire au navigateur pour mettre à jour l'interface utilisateur après l'exécution des gestionnaires d'événements.

Bien que ce délai soit important pour l'utilisateur et affecte l'expérience, il n'est pas inclus dans cette métrique, car cela pourrait inciter les développeurs à ajouter des solutions de contournement qui dégradent l'expérience. En effet, ils pourraient encapsuler leur logique de gestionnaire d'événements dans un rappel asynchrone (via setTimeout() ou requestAnimationFrame()) afin de la séparer de la tâche associée à l'événement. Il en résulte une amélioration du score de la métrique, mais une réponse plus lente telle que perçue par l'utilisateur.

Toutefois, bien que le FID ne mesure que la partie "retard" de la latence des événements, les développeurs qui souhaitent suivre une plus grande partie du cycle de vie des événements peuvent le faire à l'aide de l'API Event Timing. Pour en savoir plus, consultez le guide sur les métriques personnalisées.

Mesurer le FID

Le FID est une métrique qui ne peut être mesurée que sur le terrain, car elle nécessite qu'un utilisateur réel interagisse avec votre page. Vous pouvez mesurer le FID à l'aide des outils suivants.

Outils de terrain

• Rapport sur l'expérience utilisateur de Chrome
• PageSpeed Insights
• Search Console (rapport sur les Core Web Vitals)
• Bibliothèque JavaScript web-vitals

Mesurer le FID en JavaScript

Pour mesurer le FID en JavaScript, vous pouvez utiliser l'API Event Timing. L'exemple suivant montre comment créer un PerformanceObserver qui écoute les entrées first-input et les consigne dans la 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});

Dans l'exemple ci-dessus, la valeur de retard de l'entrée first-input est mesurée en prenant le delta entre les horodatages startTime et processingStart de l'entrée. Dans la plupart des cas, il s'agit de la valeur FID. Toutefois, toutes les entrées first-input ne sont pas valides pour mesurer le FID.

La section suivante présente les différences entre les rapports de l'API et le calcul de la métrique.

Différences entre la métrique et l'API

• L'API enverra des entrées first-input pour les pages chargées dans un onglet en arrière-plan, mais ces pages doivent être ignorées lors du calcul du FID.
• L'API distribue également des entrées first-input si la page était en arrière-plan avant la première entrée, mais ces pages doivent également être ignorées lors du calcul du FID (les entrées ne sont prises en compte que si la page était au premier plan tout le temps).
• L'API ne signale pas les entrées first-input lorsque la page est restaurée à partir du cache amélioré, mais le FID doit être mesuré dans ces cas, car les utilisateurs les perçoivent comme des visites de page distinctes.
• L'API ne signale pas les entrées qui se produisent dans les iFrames, mais la métrique le fait, car elles font partie de l'expérience utilisateur de la page. Cela peut se traduire par une différence entre CrUX et RUM. Pour mesurer correctement le FID, vous devez les prendre en compte. Les sous-cadres peuvent utiliser l'API pour signaler leurs entrées first-input au frame parent à des fins d'agrégation.

Analyser les données FID et créer des rapports les concernant

En raison de la variation attendue des valeurs FID, il est essentiel d'examiner la distribution des valeurs et de vous concentrer sur les centiles les plus élevés lorsque vous créez des rapports sur le FID.

Bien que le choix du centile pour tous les seuils Core Web Vitals soit le 75e, nous vous recommandons vivement d'examiner les 95e à 99e centiles pour le FID en particulier, car ils correspondent aux premières expériences particulièrement mauvaises des utilisateurs avec votre site. Il vous indiquera également les domaines qui nécessitent le plus d'améliorations.

Ce principe s'applique même si vous segmentez vos rapports par catégorie ou par type d'appareil. Par exemple, si vous générez des rapports distincts pour les ordinateurs et les mobiles, la valeur du FID qui vous intéresse le plus sur ordinateur doit correspondre au 95e au 99e centile des utilisateurs d'ordinateurs, et la valeur FID la plus importante sur mobile doit correspondre au 95e au 99e centile des mobinautes.

Améliorer le FID

Un guide complet sur l'optimisation du FID est disponible pour vous aider à améliorer cette métrique.

Journal des modifications

Il arrive que des bugs soient découverts dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Par conséquent, des modifications doivent parfois être apportées, et ces modifications peuvent apparaître comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.

Pour vous aider à gérer ce point, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques seront indiquées dans ce journal des modifications.

Si vous avez des commentaires concernant ces métriques, vous pouvez les envoyer dans le groupe Google "web-vitals-feedback".