Le First Input Delay (FID) mesure le temps s'écoulant entre la première interaction avec une page et le moment où le navigateur répond à cette interaction. Décryptage complet du First Input Delay

Core Web Vitals : explications en détails du First Input Delay (FID)

Les Core Web Vitals

Les Core Web Vitals sont le sous-ensemble des Web Vitals qui s'appliquent à toutes les pages Web, qui doivent être mesurées par tous les propriétaires de sites et qui seront affichées dans tous les outils Google. Chacune des Core Web Vitals représente une facette distincte de l'expérience utilisateur, est mesurable sur le terrain et reflète l'expérience réelle d'un résultat essentiel centré sur l'utilisateur.

Les indicateurs qui composent les Core Web Vitals évolueront au fil du temps. L'ensemble actuel depuis 2020 se concentre sur trois aspects de l'expérience utilisateur - le chargement (LCP - Largest Contentful Paint), l'interactivité (FID - First Input Delay) et la stabilité visuelle (CLS - Cumulative Layout Shift) - et comprend les mesures suivantes (et leurs seuils respectifs)

Nous savons tous combien il est important de faire une bonne première impression. C'est important lorsqu'on rencontre de nouvelles personnes, et c'est également important lorsqu'on construit des expériences sur le web.

Sur le web, une bonne première impression peut faire la différence entre une personne qui devient un utilisateur fidèle et une personne qui quitte le site pour ne plus y revenir. La question est de savoir ce qui constitue une bonne impression et comment mesurer le type d'impression que vous êtes susceptible de faire sur vos utilisateurs.

Sur le Web, la première impression peut prendre des formes très diverses : la première impression est celle de la conception et de l'attrait visuel d'un site, mais aussi celle de sa vitesse et de sa réactivité.

S'il est difficile de mesurer à quel point les utilisateurs apprécient la conception d'un site avec les API Web, il n'en va pas de même pour sa vitesse et sa réactivité !

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

Le délai de première entrée (FID) 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 First Input Delay (FID) ?

Le First Input Delay (FID) mesure l'interactivité. Tout comme le LCP, il s'agit également d'une mesure essentielle et centrée sur l'utilisateur, qui quantifie l'expérience vécue par les utilisateurs lorsqu'ils tentent d'interagir avec des pages non réactives. Il se traduit par la perception globale de la facilité d'utilisation de votre page Web.

Le FID vise à quantifier le temps entre la première interaction de l'utilisateur sur le web (cliquer sur un lien, appuyer sur un bouton...) et le moment où votre navigateur web peut commencer à traiter un tel événement.

Il est également lié à ce que l'on appelle communément la latence d'entrée. Des temps de latence plus longs se produisent lorsque le thread principal du navigateur web est occupé à effectuer d'autres opérations et ne peut donc pas réagir à l'entrée de l'utilisateur. Il y a de nombreuses raisons à cela - elles sont souvent liées à l'analyse et au traitement de fichiers JavaScript complexes chargés par votre site Web ou votre application.

Il existe plusieurs bonnes raisons pour lesquelles le FID ne traite que la première entrée. La première raison est que le délai de la première entrée sera probablement la première expérience d'un utilisateur sur votre site Web, et si cette première impression est mauvaise, elle façonnera probablement la perception générale du site Web. En outre, les problèmes d'interactivité les plus importants surviennent généralement pendant le chargement de la page. Ainsi, le fait de se concentrer sur ces premières interactions aura probablement l'effet le plus important.

Quel est un bon score FID ?

Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir un délai de première saisie de 100 millisecondes ou moins. Pour vous assurer que vous atteignez cet objectif pour la plupart de vos utilisateurs, un bon seuil à mesurer est 75% de chargements de pages, segmenté entre les appareils mobiles et de bureau.

Le First Input Delay en détail

En tant que développeurs qui écrivent du code répondant à des é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 fait l'expérience du contraire : il nous est arrivé de charger une page Web sur notre téléphone, d'essayer d'interagir avec elle, puis d'être frustrés lorsque rien ne se passait.

En général, le input delay (aussi appelé latence d'entrée) se produit parce que le fil d'exécution principal du navigateur est occupé à faire autre chose, et 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 ce temps, il ne peut pas exécuter d'écouteurs d'événements car le JavaScript qu'il charge pourrait lui demander de faire autre chose.

Attention ! Le FID ne mesure que le "retard" dans le traitement des événements. Il ne mesure pas le temps de traitement de l'événement lui-même ni le temps que met le navigateur à mettre à jour l'interface utilisateur après l'exécution des gestionnaires d'événements. Bien que ce temps affecte l'expérience de l'utilisateur, l'inclure dans le FID inciterait les développeurs à répondre aux événements de manière asynchrone, ce qui améliorerait la mesure mais aggraverait probablement l'expérience.

Considérez la chronologie suivante d'un chargement typique de page web :

La visualisation ci-dessus montre une page qui effectue quelques requêtes réseau (network request) pour des ressources (très probablement des fichiers CSS et JS) et qui, une fois le téléchargement de ces ressources terminé, est traitée par le fil principal (main thread).

Il en résulte des périodes où le main thread est momentanément occupé, ce qui est indiqué par les blocs de tâches de couleur beige.

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 rendu une partie de son contenu mais n'est pas encore interactive de manière fiable. Pour illustrer comment cela peut se produire, First Contentful Paint (FCP) et Time to Interactive (TTI) ont été ajoutés au graphique :

Vous avez peut-être remarqué qu'il y a un certain temps (en incluant les trois tâches longues) entre FCP et TTI, si un utilisateur essaie d'interagir avec la page pendant ce temps (par exemple cliquer sur un lien), il y aura un délai entre le moment où le clic est reçu et le moment où le thread principal est capable de répondre.

Imaginez ce qui se passerait si un utilisateur essayait d'interagir avec la page vers le début de la tâche la plus longue :

Comme l'entrée se produit alors que le navigateur est en train d'exécuter une tâche, il doit attendre que la tâche se termine avant de pouvoir répondre à l'entrée. Le temps qu'il doive attendre est la valeur First Input Delay (FID) de cet utilisateur sur cette page.

Dans cet exemple, il se trouve que l'utilisateur a interagi avec la page au début de la période la plus chargée du fil principal. Si l'utilisateur avait interagi avec la page juste un instant plus tôt (pendant la période d'inactivité), le navigateur aurait pu répondre immédiatement. Cette variance dans le délai d'entrée souligne l'importance d'examiner la distribution des valeurs First Input Delay (FID) lors de l'établissement du rapport sur la métrique.

Que faire si une interaction n'a pas de récepteur d'événements ?

Le First Input Delay (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 ensuite inactif. Cela signifie que le FID est mesuré même dans les cas où un récepteur d'événements n'a pas été enregistré. La raison en est que de nombreuses interactions avec l'utilisateur ne nécessitent pas de récepteur d'événements mais exigent que le thread principal soit inactif pour fonctionner.

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>)
• Les listes déroulantes de sélection (<select>)
• Les liens (<a>)

Pourquoi ne considérer que la première entrée (le First Imput) ?

Bien qu'un retard de n'importe quelle entrée puisse conduire à une mauvaise expérience utilisateur, nous recommandons principalement de mesurer le retard de la première entrée pour quelques raisons :

• Le délai de première entrée sera la première impression de l'utilisateur sur la réactivité de votre site, et les premières impressions sont essentielles pour façonner notre impression générale de la qualité et de la fiabilité d'un site.
• Les plus gros problèmes d'interactivité que nous observons aujourd'hui sur le web se produisent pendant le chargement des pages. Par conséquent, nous pensons que le fait de se concentrer sur l'amélioration de la première interaction de l'utilisateur avec le site aura le plus grand impact sur l'amélioration de l'interactivité globale du web.
• Les solutions recommandées pour résoudre les problèmes de délais d'entrée élevés (division du code, chargement de moins de JavaScript en amont, etc.) ne sont pas nécessairement les mêmes que pour les délais d'entrée lents après le chargement de la page. ) ne sont pas nécessairement les mêmes que pour les retards de saisie après le chargement de la page. En séparant ces mesures, nous serons en mesure de fournir des directives de performance plus spécifiques aux développeurs web.

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

Le First Input Delay (FID) est un indicateur qui mesure la réactivité d'une page pendant son chargement. En tant que tel, il se concentre uniquement sur les événements d'entrée provenant d'actions discrètes comme les clics, les tapotements et les pressions sur les touches. D'autres interactions, comme le défilement et le zoom, sont des actions continues et ont des contraintes de performance complètement différentes (de plus, les navigateurs sont souvent capables de cacher leur latence en les exécutant sur un thread séparé).

En d'autres termes, le FID se concentre sur le R (réactivité) du modèle de performance RAIL, tandis que le défilement et le zoom sont davantage liés au 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 ne vont pas interagir avec votre site à chaque visite. Et toutes les interactions ne sont pas pertinentes pour le FID (comme mentionné dans la section précédente). En outre, les premières interactions de certains utilisateurs auront lieu à des moments difficiles (lorsque le fil principal est occupé pendant une longue période), et les premières interactions de certains utilisateurs auront lieu à des moments favorables (lorsque le fil principal est complètement inactif).

Cela signifie que certains utilisateurs n'auront pas de valeurs First Input Delay (FID) , d'autres auront des valeurs First Input Delay (FID) faibles et d'autres encore auront probablement des valeurs FID élevées.

La façon dont vous suivez, rapportez et analysez le First Input Delay (FID) sera probablement assez différente des autres mesures auxquelles vous êtes habitué. La section suivante explique la meilleure façon de procéder.

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

Comme mentionné ci-dessus, le First Input Delay (FID) ne mesure que le "retard" dans le traitement des événements. Il ne mesure pas le temps de traitement de l'événement 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.

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

Cependant, alors que les FID ne mesurent 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 en utilisant l'API Event Timing.

Comment mesurer le First Input Delay ?

Le FID est un indicateur qui ne peut être mesuré que sur le terrain, car il nécessite l'interaction d'un utilisateur réel avec votre page. Vous pouvez mesurer le FID avec les outils suivants.

Outils de terrain

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

Mesure du First Input Delay (FID) en JavaScript

Pour mesurer le First Input Delay (FID) en JavaScript, vous pouvez utiliser l'API Event Timing. L'exemple suivant montre comment créer un PerformanceObserver qui écoute les entrées de première entrée et les enregistre 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 du retard de l'entrée de première entrée 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 de première entrée ne sont pas valides pour mesurer le First Input Delay (FID).

La section suivante énumère les différences entre ce que l'API rapporte et la façon dont la métrique est calculée.

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

• L'API enverra les entrées de première entrée pour les pages chargées dans un onglet d'arrière-plan, mais ces pages doivent être ignorées lors du calcul du First Input Delay (FID).
• L'API envoie également les entrées de première entrée si la page a été mise en arrière-plan avant que la première entrée ne se produise, 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 pendant toute la durée de l'opération).
• L'API ne signale pas les entrées de première saisie lorsque la page est restaurée à partir du cache arrière/avant, mais le First Input Delay (FID) doit être mesuré dans ces cas puisque les utilisateurs les perçoivent comme des visites de pages distinctes.
• L'API ne signale pas les entrées qui se produisent dans les iframes, mais pour mesurer correctement le First Input Delay (FID), vous devez les prendre en compte. Les sous-cadres peuvent utiliser l'API pour signaler leurs entrées de première entrée au cadre parent pour l'agrégation.

Plutôt que de mémoriser toutes ces différences subtiles, les développeurs peuvent utiliser la bibliothèque JavaScript web-vitals pour mesurer le FID, qui gère ces différences pour vous (dans la mesure du possible) :

import {getFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
getFID(console.log);

Vous pouvez vous référer au code source de getFID pour un exemple complet de la façon de mesurer le First Input Delay (FID) en JavaScript.

Analyse et rapport des données FID

En raison de la variance attendue des valeurs du FID, il est essentiel, lorsque vous établissez un rapport sur le FID, d'examiner la distribution des valeurs et de vous concentrer sur les percentiles supérieurs.

Bien que le choix du pourcentage pour tous les seuils de Core Web Vitals soit le 75ème, pour le First Input Delay (FID) en particulier, nous recommandons fortement de regarder les 95% et 99%, car ils correspondent aux premières expériences particulièrement mauvaises des utilisateurs avec votre site. Et cela vous montrera les domaines qui nécessitent le plus d'améliorations.

Cela est vrai même si vous segmentez vos rapports par catégorie ou type d'appareil. Par exemple, si vous exécutez des rapports distincts pour les ordinateurs de bureau et les téléphones portables, la valeur FID qui vous intéresse le plus pour les ordinateurs de bureau devrait être 95% - 99% des utilisateurs d'ordinateurs de bureau, et la valeur FID qui vous intéresse le plus pour les téléphones portables devrait être 95% - 99% des utilisateurs de téléphones portables.

Comment améliorer le First Input Delay (FID) ?

Pour savoir comment améliorer le FID d'un site spécifique, vous pouvez exécuter un audit de performance Lighthouse et prêter attention à toute opportunité spécifique suggérée par l'audit.

Bien que le FID soit une mesure de terrain (et que Lighthouse soit un outil de mesure de laboratoire), les conseils pour améliorer le FID sont les mêmes que pour améliorer la mesure de laboratoire Temps de blocage total (TBT).

Pour une analyse approfondie de la manière d'améliorer le FID, voir Optimiser le FID. Pour des conseils supplémentaires sur les techniques de performance individuelles qui peuvent également améliorer le FID, voir :

• Réduire l'impact du code tiers
• Réduire le temps d'exécution du JavaScript
• Minimiser le travail du thread principal
• Maintenir le nombre de requêtes à un niveau bas et la taille des transferts à un niveau faible

CHANGELOG

De temps en temps, des bogues sont découverts dans les API utilisées pour mesurer les indicateurs, et parfois dans les définitions des indicateurs eux-mêmes. En conséquence, 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 cela, tous les changements apportés à l'implémentation ou à la définition de ces mesures seront présentés dans ce CHANGELOG.

Article mis à jour le 09 novembre 2021