Nous savons tous à quel point il est important de faire bonne 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 la suivante : qu'est-ce qui fait bonne impression et comment mesurer le type d'impression que vous faites probablement sur vos utilisateurs ?
Sur le Web, les premières impressions peuvent prendre de nombreuses formes. Nous avons des premières impressions sur la conception et l'attrait visuel d'un site, ainsi que sur sa vitesse et 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 à l'aide du First Contentful Paint (FCP). Mais la vitesse à laquelle votre site peut peindre des pixels à l'écran n'est qu'une partie de l'histoire. Il est tout aussi important de savoir à quel point votre site est responsif 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 de ne pas dépasser un délai de première saisie de 100 millisecondes. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, un bon seuil à mesurer est le 75e centile des chargements de pages, segmentés par appareil mobile et ordinateur.
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 de ce problème 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 d'un chargement de page Web typique:
La visualisation ci-dessus montre une page qui effectue quelques requêtes réseau pour des ressources (très probablement des fichiers CSS et JS). Une fois le téléchargement de ces ressources terminé, elles sont traitées sur le thread principal.
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 ce phénomène, le FCP et le TTI ont été ajoutés à la chronologie:
Vous avez peut-être remarqué qu'un certain temps s'écoule (y compris trois tâches longues) entre le FCP et le TTI. Si un utilisateur tente d'interagir avec la page pendant ce temps (par exemple, en cliquant sur un lien), un délai s'écoule entre le moment où le clic est reçu et celui où le thread principal peut 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 s'exécuter.
Par exemple, tous les éléments HTML suivants doivent attendre que les tâches en cours sur le thread principal soient terminées 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 retard de saisie puisse entraîner une mauvaise expérience utilisateur, nous vous recommandons principalement de mesurer le premier retard de saisie 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 plus gros problèmes d'interactivité que nous observons sur le Web aujourd'hui 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 pendant le chargement. Par conséquent, il ne se concentre que sur les événements d'entrée provenant d'actions distinctes telles que les clics, les appuis et les pressions de touches.
D'autres interactions, comme le défilement et le zoom, sont des actions continues et ont des contraintes de performances complètement différentes (en outre, les navigateurs peuvent souvent masquer leur latence en les exécutant sur un thread distinct).
En d'autres termes, le FID se concentre sur la R (réactivité) du modèle de performances RAIL, tandis que le défilement et le zoom sont davantage liés à l'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 le 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, créez des rapports et analysez le FID sera probablement très différente des autres métriques que vous connaissez. 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 "retard" du traitement des événements. Il ne mesure pas la durée totale de traitement des événements ni le temps qu'il faut au navigateur pour mettre à jour l'UI 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. 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, bien que le 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. 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 sur le terrain
- Rapport sur l'expérience utilisateur de Chrome
- PageSpeed Insights
- Search Console (rapport 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 délai de l'entrée first-input est mesurée en prenant le delta entre les codes temporels 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 distribue des entrées
first-inputpour 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-inputsi 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-inputlorsque la page est restaurée à partir du cache avant/arrière, mais le FID doit être mesuré dans ce cas, car 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 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-inputau frame parent à des fins d'agrégation.
Analyser et créer des rapports sur les données FID
En raison de la variance attendue des valeurs FID, il est essentiel, lorsque vous créez des rapports sur le FID, d'examiner la distribution des valeurs et de vous concentrer sur les percentiles les plus élevés.
Bien que le choix du percentile pour tous les seuils des métriques Core Web Vitals soit le 75e, nous vous recommandons vivement d'examiner les percentiles 95e à 99e pour le FID en particulier, car ils correspondent aux premières expériences particulièrement mauvaises que les utilisateurs ont avec votre site. Il vous indiquera également 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 ordinateur et mobile, la valeur FID qui vous intéresse le plus sur ordinateur doit correspondre au 95e et 99e centile des utilisateurs d'ordinateurs, et la valeur FID qui vous intéresse le plus sur mobile doit correspondre au 95e et 99e centile des utilisateurs de mobiles.
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 parfois que des bugs soient détectés 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 sous la forme d'améliorations ou de 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 sur ces métriques, vous pouvez les envoyer dans le groupe Google web-vitals-feedback.