First Input Delay (FID)

Nous savons tous à quel point il est important de faire une bonne première impression. C’est important lorsque l’on rencontre de nouvelles personnes, et c’est également important lors de la création d’expériences sur le Web.

Sur le web, une bonne première impression peut faire la différence entre quelqu’un qui devient un utilisateur fidèle ou qui part et ne revient jamais. La question est de savoir qu’est-ce qui fait une bonne impression et comment mesurez-vous le type d’impression que vous faites probablement à vos utilisateurs ?

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

S’il est difficile de mesurer à quel point les utilisateurs aiment la conception d’un site avec des API Web, mesurer sa vitesse et sa réactivité ne l’est pas !

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. Tout aussi important est la réactivité de votre site lorsque les utilisateurs essaient d’interagir avec ces pixels !

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

Qu’est-ce que le FID ?

FID mesure le temps 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 un contrôle personnalisé alimenté par JavaScript) jusqu’au moment où le navigateur est réellement en mesure de commencer à traiter les gestionnaires d’événements en réponse à cette interaction.

Qu’est-ce qu’un bon score FID ?

Pour offrir une bonne expérience utilisateur, les sites doivent s’efforcer d’avoir un délai de première entrée de 100 millisecondes ou moins.

FID en détail

En tant que développeurs qui écrivent du code qui répond aux événements, nous supposons souvent que notre code va être exécuté immédiatement, dès que l’événement se produit. Mais en tant qu’utilisateurs, nous avons tous souvent vécu le contraire : nous avons chargé une page Web sur notre téléphone, essayé d’interagir avec elle, puis nous avons été frustrés quand rien ne s’est passé.

En général, le délai d’entrée (également appelé latence d’entrée) se produit parce que le fil principal du navigateur est occupé à faire autre chose, 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 gros fichier JavaScript chargé par votre application. Pendant qu’il fait cela, il ne peut exécuter aucun écouteur d’événement car le JavaScript qu’il charge peut lui dire de faire autre chose.

Que faire si une interaction n’a pas d’écouteur d’événement ?

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 le prochain inactif. Cela signifie que le FID est mesuré même dans les cas où un d’événement n’a pas été enregistré. La raison en est que de nombreuses interactions utilisateur ne nécessitent pas d’écouteur d’événements, mais nécessitent que le thread principal soit inactif pour 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 de l’utilisateur :

• Champs de texte, cases à cocher et boutons radio (<input>, <textarea>)
• Select dropdowns (<select>)
• links (<a>)

Pourquoi ne considérer que la première entrée ?

Bien qu’un retard de n’importe quelle entrée puisse entraîner une mauvaise expérience utilisateur, nous recommandons principalement de mesurer le premier retard d’entrée pour plusieurs raisons :

• Le premier délai d’entrée sera la première impression de l’utilisateur de la réactivité de votre site, et les premières impressions sont essentielles pour façonner notre impression globale de la qualité et de la fiabilité d’un site.
• Les plus gros problèmes d’interactivité que nous voyons sur le Web aujourd’hui surviennent lors du chargement de la page. Par conséquent, nous pensons que se concentrer initialement sur l’amélioration de la première interaction avec l’utilisateur du site aura le plus grand impact sur l’amélioration de l’interactivité globale du Web.
• The recommended solutions for how sites should fix high first input delays (code splitting, loading less JavaScript upfront, etc.) are not necessarily the same solutions for fixing slow input delays after page load. By separating out these metrics we’ll be able to provide more specific performance guidelines to web developers.

Qu’est-ce qui compte comme première entrée ?

Le FID est une métrique qui mesure la réactivité d’une page pendant le chargement. En tant que tel, il se concentre uniquement sur les événements d’entrée provenant d’actions discrètes telles que les clics et les pressions sur les touches.

D’autres interactions, comme le scroll et le zoom, sont des actions continues et ont des contraintes de performances complètement différentes (de plus, les navigateurs sont souvent capables de masquer leur latence en les exécutant sur un thread séparé).

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

Que faire si un utilisateur n’interagit jamais avec votre site ?

Tous les utilisateurs n’interagiront pas avec votre site à chaque visite. Et toutes les interactions ne sont pas pertinentes pour le FID (comme mentionné dans la section précédente). De plus, les premières interactions de certains utilisateurs auront lieu à de mauvais moments (lorsque le thread principal est occupé pendant une période prolongée) et les premières interactions de certains utilisateurs seront à de bons moments (lorsque le thread principal est complètement inactif).

Cela signifie que certains utilisateurs n’auront pas de valeurs FID, certains utilisateurs auront des valeurs FID faibles et certains utilisateurs auront probablement des valeurs FID élevées.

La façon dont vous suivez, faites rapport et analysez le FID sera probablement assez différente des autres mesures auxquelles vous êtes peut-être habitué. La section suivante explique comment procéder au mieux.

Pourquoi ne considérer que le délai d’entrée ?

Comme mentionné ci-dessus, FID ne mesure que le « retard » dans le traitement des événements. Il ne mesure pas le temps de traitement des événements lui-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.

Même si ce temps est 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 aggravent réellement l’expérience, c’est-à-dire qu’ils pourraient envelopper leur logique de gestionnaire d’événements dans un processus asynchrone.

Cependant, bien que FID ne mesure que la partie « retard » de la latence de l’événement, les développeurs qui souhaitent suivre davantage le cycle de vie de l’événement peuvent le faire à l’aide de l’API Event Timing. Consultez le guide sur les métriques personnalisées pour plus de détails.

Comment améliorer le FID

Pour savoir comment améliorer le FID pour un site spécifique, vous pouvez exécuter un audit de performance Lighthouse et prêter attention aux opportunités spécifiques suggérées par l’audit.

Pour plus d’informations vous pouvez retrouver l’origine de cette article en anglais