Nous savons tous à quel point il est important de faire une bonne première impression. C'est important pour rencontrer de nouvelles personnes, mais aussi pour créer 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 le fait qu'il quitte le site et ne le revienne jamais. La question est de savoir ce qui fait une bonne impression et comment mesurer le type d'impression que vous êtes susceptible de donner à vos utilisateurs.
Sur le Web, les premières impressions peuvent prendre de nombreuses formes. Elles nous donnent une première impression de la conception et de l'aspect visuel du site, mais aussi des premières impressions de sa vitesse et de sa réactivité.
Bien qu'il soit difficile de mesurer à quel point les utilisateurs apprécient la conception d'un site avec des API Web, il est impossible de mesurer sa vitesse et sa réactivité.
La première impression des utilisateurs quant à la vitesse de chargement de votre site peut être mesurée avec First Contentful Paint (FCP). Mais la vitesse à laquelle votre site peut afficher des pixels à l'écran n'est qu'une partie de l'histoire. Il est tout aussi important de déterminer la réactivité de votre site lorsque les utilisateurs essaient d'interagir avec ces pixels.
La métrique FID (First Input Delay) permet de mesurer la première impression de l'utilisateur concernant 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 (lorsqu'il clique sur un lien, appuie sur un bouton ou utilise une commande personnalisée JavaScript) et le moment où le navigateur est 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 expérience utilisateur de qualité, les sites doivent s'efforcer de définir un First Input Delay de 100 millisecondes au maximum. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, le 75e centile des chargements de page est un bon seuil à mesurer, segmenté entre les appareils mobiles et les ordinateurs.
Le FID en détail
Lorsque les développeurs écrivent du code en réponse à des événements, nous supposons souvent que notre code va s'exécuter immédiatement, dès que l'événement se produit. Mais en tant qu'utilisateurs, nous avons tous souvent vécu l'inverse : nous avons chargé une page Web sur notre téléphone, essayé d'interagir avec elle, puis nous avons été frustrés lorsqu'il ne s'est rien passé.
En général, le délai d'entrée (ou latence d'entrée) se produit lorsque le thread principal du navigateur est occupé à effectuer autre chose. Il ne peut donc pas (encore) répondre à l'utilisateur. L'une des raisons les plus courantes est que le navigateur est occupé à analyser et exécuter un fichier JavaScript volumineux chargé par votre application. Pendant ce temps, il ne peut exécuter aucun écouteur d'événements, car le code JavaScript chargé peut lui indiquer d'effectuer une autre opération.
Considérez la chronologie suivante pour le chargement d'une page Web:
La visualisation ci-dessus montre une page qui envoie quelques requêtes réseau pour des ressources (probablement des fichiers CSS et JS). Une fois le téléchargement de ces ressources terminé, elles sont traitées sur le thread principal.
Il en résulte des périodes au cours desquelles le thread principal est momentanément occupé, comme indiqué par les blocs de tâche beiges.
Les premiers délais de saisie sont généralement trop longs entre le First Contentful Paint (FCP) et le Délai avant interactivité (TTI), car la page affiche une partie de son contenu, mais n'est pas encore interactive de manière fiable. Pour illustrer la façon dont 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 FCP et 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 l'entrée a lieu lorsque le navigateur est en train d'exécuter une tâche, il doit attendre qu'elle soit terminée avant de pouvoir y répondre. Le temps d'attente correspond à la valeur du 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 la réception d'un événement d'entrée et le prochain délai d'inactivité du thread principal. Cela signifie que le FID est mesuré même dans les cas où aucun écouteur d'événements n'a é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 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 cases d'option (
<input>,<textarea>) - Sélectionner des menus déroulants (
<select>) - lien (
<a>)
Pourquoi ne prendre en compte que la première entrée ?
Bien qu'un retard de n'importe quelle entrée puisse nuire à l'expérience utilisateur, nous vous recommandons principalement de mesurer le premier délai d'entrée pour plusieurs raisons:
- Le premier délai d'entrée 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 sommes convaincus que le fait de se concentrer au départ sur l'amélioration de la première interaction utilisateur sur le site aura le plus d'impact sur l'amélioration de l'interactivité globale sur le Web.
- Les solutions recommandées pour résoudre les délais d'entrée élevés au début (répartition du code, moins de JavaScript à l'avance, etc.) ne sont pas nécessairement les mêmes pour résoudre les problèmes de lenteur de saisie après le chargement de la page. En séparant ces métriques, nous pourrons fournir aux développeurs Web des consignes plus spécifiques concernant les performances.
Qu'est-ce qui est considéré comme première entrée ?
Le FID est une métrique qui mesure la réactivité d'une page pendant son 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 appuis sur des touches.
D'autres interactions, telles que le défilement et le zoom, sont des actions continues qui présentent des contraintes de performances complètement différentes. De plus, les navigateurs peuvent souvent masquer leur latence en les exécutant sur un thread distinct.
En d'autres termes, 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'interagissent 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). En outre, les premières interactions de certains utilisateurs se produisent à de mauvais moments (lorsque le thread principal est occupé pendant une période prolongée), et les premières interactions de certains utilisateurs se produisent au bon moment (lorsque le thread principal est complètement inactif).
Cela signifie que certains utilisateurs n'auront pas de valeurs FID, d'autres auront des valeurs FID faibles et d'autres auront probablement des valeurs FID élevées.
La façon dont vous effectuez le suivi, le reporting et l'analyse du FID sera probablement très différent des autres métriques auxquelles vous êtes peut-être habitué. La section suivante explique la meilleure façon de procéder.
Pourquoi ne prendre en compte que le délai d'entrée ?
Comme indiqué ci-dessus, le FID ne mesure que le "retard" dans le traitement des événements. Elle ne mesure pas le temps de traitement des événements proprement dit, 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 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 nuisent à l'expérience. Autrement dit, ils pourraient encapsuler la logique de leur 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 dans le champ, car il 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 Chrome
- PageSpeed Insights
- Search Console (rapport Core Web Vitals)
- Bibliothèque JavaScript
web-vitals
Mesurer le FID dans 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 horodatages startTime et processingStart de l'entrée. Dans la plupart des cas, il s'agira de la valeur du FID. Toutefois, toutes les entrées first-input ne sont pas valides pour mesurer le FID.
La section suivante répertorie les différences entre les rapports générés par l'API et le mode de calcul de la métrique.
Différences entre la métrique et l'API
- L'API envoie 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 envoie également des entrées
first-inputsi la page a été mise en arrière-plan avant l'apparition de 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 exécutée au premier plan pendant toute la durée). - L'API ne signale pas les entrées
first-inputlorsque la page est restaurée à partir du cache amélioré, mais le FID doit être mesuré dans ces cas, car les utilisateurs les voient comme des 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 sur la page. Cela peut montrer comme une différence entre CrUX et RUM.
Pour mesurer correctement le FID, vous devez les prendre en compte. Les sous-frames peuvent utiliser l'API pour signaler leurs entrées
first-inputau frame parent à des fins d'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, ce qui gère ces différences pour vous (dans la mesure du possible, le problème iFrame n'est pas couvert):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
Vous pouvez consulter le code source de onFID() pour obtenir un exemple complet de mesure du FID en JavaScript.
Analyser des données FID et créer des rapports les concernant
En raison de la variance attendue des valeurs FID, lorsque vous créez des rapports sur le FID, il est essentiel que vous examiniez la distribution des valeurs et que vous vous concentriez sur les centiles les plus élevés.
Bien que le choix du centile pour tous les seuils Core Web Vitals soit le 75e, nous vous recommandons vivement d'examiner en particulier les 95e et 99e centiles pour le FID, car ils correspondront aux premières expériences particulièrement mauvaises pour les utilisateurs de votre site. Et il vous indiquera les domaines à améliorer.
Ce principe s'applique même si vous segmentez vos rapports par catégorie ou 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 importe le plus sur ordinateur doit correspondre au 95e au 99e centile des utilisateurs d'ordinateurs, et la valeur FID qui vous importe le plus sur mobile doit correspondre au 95e à 99e centile des utilisateurs mobiles.
Améliorer le FID
Un guide complet sur l'optimisation du FID est disponible pour vous guider dans les techniques permettant d'améliorer cette métrique.
Journal des modifications
Des bugs sont parfois découverts dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Des modifications doivent donc parfois être apportées, et ces modifications peuvent se présenter comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.
Pour vous aider, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques seront affichées dans ce journal des modifications.
Si vous avez des commentaires sur ces métriques, vous pouvez les faire dans le groupe Google web-vitals-feedback.