Nous savons tous à quel point il est important de faire une bonne première impression. C'est important lorsque vous rencontrez de nouvelles personnes. C'est aussi important lorsque vous créez des expériences sur sur le Web.
Sur le Web, une bonne première impression peut faire la différence devenir un utilisateur fidèle, ou qu’il démissionne et ne revienne jamais. La question est : ce qui fait une bonne impression, et comment mesurer le type d'impression que vous générez probablement sur vos utilisateurs ?
Sur le Web, la première impression peut prendre de nombreuses formes. les premières impressions de la conception et de l'attrait visuel d'un site, impressions 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, 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. Il est tout aussi important de savoir à quel point lorsque les utilisateurs essaient d'interagir avec ces pixels.
La métrique FID (First Input Delay) permet de mesurer la première impression de votre utilisateur l'interactivité et la réactivité de votre site.
Qu’est-ce que le FID ?
Le FID mesure le temps écoulé entre le moment où un utilisateur interagit pour la première fois avec une page (c'est-à-dire, il clique sur un lien, appuie sur un bouton ou utilise une commande JavaScript personnalisée) au 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 fournir une première entrée Délai de 100 millisecondes ou moins Pour être sûr d'atteindre cet objectif pour la plupart de vos utilisateurs, le 75e centile chargements de page, segmentés 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 va s'exécuter immédiatement, dès que l'événement se produit. Mais en tant qu'utilisateurs, nous avons souvent fait l'expérience contraire : nous avons chargé une page Web sur notre téléphone, a essayé d'interagir avec, puis il a été frustré quand rien s'est produit.
En général, le délai d'entrée (latence d'entrée) se produit parce que le thread principal est occupé à faire autre chose, il ne peut donc pas (encore) répondre à l'utilisateur. Cela peut se produire lorsque le navigateur est occupé à analyser et exécuter un fichier JavaScript volumineux chargé par votre application. Pendant ce temps, il ne peut pas s'exécuter n'importe quel écouteur d'événements, car le code JavaScript chargé 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 les ressources (généralement des fichiers CSS et JS), sont terminés et sont traités sur le thread principal.
Cela se traduit par des périodes où le thread principal est temporairement occupé, ce qui indiqué par la couleur beige tâche blocs.
Les délais de première entrée sont généralement plus longs que la période First Contentful Paint (FCP) et Time to Interactive (TTI), car la page comporte a affiché une partie de son contenu, mais n'est pas encore vraiment interactif. Pour illustrer comment cela peut se produire, le FCP et le TTI ont été ajoutés à la chronologie:
Vous avez peut-être remarqué que le délai est long (y compris trois tâches) entre le FCP et le TTI, si un utilisateur d'interagir avec la page pendant ce laps de temps (par exemple, en cliquant sur un lien), un délai entre le moment où le clic est reçu et le moment où le thread principal est en mesure de répondre.
Réfléchissez à ce qui se passerait si un utilisateur essayait d'interagir avec la page à proximité de la au début de la tâche la plus longue:
Comme l'entrée se produit pendant que le navigateur est en train d'exécuter une tâche, il doit attendre la fin de la tâche avant de pouvoir répondre à l'entrée. La temps d’attente est la valeur FID pour cet utilisateur sur cette page.
Que se passe-t-il si une interaction n'est pas associée à un écouteur d'événements ?
Le FID mesure le delta entre la réception d'un événement d'entrée et le moment où Le thread suivant est inactif. Cela signifie que le FID est mesuré même dans les cas où un événement "listener" n'a pas été enregistré. En effet, de nombreuses interactions utilisateur n'ont pas besoin d'un écouteur d'événements, mais ont besoin que le thread principal soit inactif dans d'exécution.
Par exemple, tous les éléments HTML suivants doivent attendre tâches en cours sur le thread principal à effectuer avant de répondre à l'utilisateur interactions:
- Champs de texte, cases à cocher et cases d'option (
<input>,<textarea>) - Sélectionner un menu déroulant (
<select>) - liens (
<a>)
Pourquoi ne prendre en compte que la première entrée ?
Même si un certain délai d'affichage d'une entrée peut nuire à l'expérience utilisateur, nous nous efforçons Il est recommandé de mesurer le premier délai d'entrée pour plusieurs raisons:
- Le premier délai d'entrée est la première impression qu'a l'utilisateur de la page la réactivité et les premières impressions sont des facteurs essentiels pour façonner de la qualité et de la fiabilité d'un site.
- Les plus gros problèmes d'interactivité que nous constatons aujourd'hui sur le Web se produisent pendant de votre application. Par conséquent, nous pensons que, dans un premier temps, nous attachons une grande importance à l'amélioration d'interaction auront le plus d'impact sur l'amélioration l'interactivité du Web.
- Solutions recommandées pour résoudre les problèmes liés aux retards importants liés à la première entrée des sites (scission du code, chargement de moins de JavaScript à l'avance, etc.) ne sont pas nécessairement les mêmes solutions pour corriger les retards de saisie lents après le chargement de la page. En séparant ces métriques, nous serons en mesure de fournir pour les 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. À ce titre, se concentre uniquement sur les événements d'entrée provenant d'actions discrètes telles que les clics, les appuis et les touches d'appui.
D'autres interactions, comme le défilement et le zoom, sont des actions continues qui ont des contraintes de performances complètement différentes (les navigateurs sont souvent capables masquer leur latence en les exécutant sur un thread distinct).
En d'autres termes, le FID se concentre sur le R (réactivité) de la RAIL performances de ML, tandis que le défilement et le zoom sont davantage liés à A (animation), et à leurs performances les qualités 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. Et pas tous les interactions sont pertinentes pour le FID (comme indiqué dans la section précédente). Dans De plus, les premières interactions de l'utilisateur se feront à des mauvais moments (lorsque les est occupé pendant une période prolongée), et les premiers les interactions ont lieu au bon moment (lorsque le thread principal est complètement inactif).
Cela signifie que certains utilisateurs n'auront pas de valeur FID, d'autres auront un FID faible et certains utilisateurs auront probablement des valeurs FID élevées.
La façon dont vous suivez, signalez et analysez le FID sera probablement très différente à partir d'autres métriques auxquelles vous êtes peut-être habitué. La section suivante explique la meilleure façon de procéder cette étape.
Pourquoi ne tenir compte que du délai d'entrée ?
Comme mentionné ci-dessus, le FID ne mesure que le "retard" lors du traitement des événements. Oui ne mesurent pas la durée totale de traitement des événements ni le temps nécessaire le navigateur pour mettre à jour l'interface utilisateur après avoir exécuté des gestionnaires d'événements.
Même si ce temps est important pour l'utilisateur et affecte son expérience,
elles ne sont pas incluses dans cette métrique, car cela pourrait inciter les développeurs
d'ajouter des solutions qui aggravent l'expérience,
pourrait encapsuler sa logique de gestionnaire d'événements dans un rappel asynchrone (via
setTimeout() ou requestAnimationFrame()) afin de la séparer du
associée à l'événement. Il en résulte une amélioration de la métrique
mais une réponse plus lente
comme perçue par l'utilisateur.
Toutefois, alors que le FID ne mesure que le "retard" de 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'outil Event Timing API. Consultez le guide sur les paramètres métriques pour en savoir plus.
Mesurer le FID
Le FID est une métrique qui ne peut être mesurée que dans le , car il nécessite un vrai champ d'interagir avec votre page. Vous pouvez mesurer le FID à l'aide des outils suivants.
Outils de terrain
- Expérience utilisateur Chrome Rapport
- PageSpeed Insights
- Search Console (Core Web Vitals) rapport)
- Bibliothèque JavaScript
web-vitals
Mesurer le FID en JavaScript
Pour mesurer le FID en JavaScript, vous pouvez utiliser la colonne Durée de l'événement
API. L'exemple suivant montre comment
créer un
PerformanceObserver
qui écoute
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 par
en prenant le delta entre les valeurs startTime et processingStart de l'entrée
codes temporels. Dans la plupart des cas, il s’agira
de la valeur FID ; mais pas tous
Les entrées first-input permettent de mesurer le FID.
La section suivante répertorie les différences entre les rapports de l'API et le fonctionnement la métrique est calculée.
Différences entre la métrique et l'API
- L'API enverra
first-inputentrées 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 enverra également des entrées
first-inputsi 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 se trouve dans au premier plan tout le temps). - L'API ne signale pas les entrées
first-inputlorsque la page est restaurée à partir de dans le cache amélioré, mais le FID être mesuré dans ces cas, car les utilisateurs les perçoivent comme des pages Web distinctes visites. - L'API ne signale pas les entrées qui se produisent au sein d'iFrames, mais la métrique le fait.
car ils font partie de l'expérience
utilisateur de la page. Cela peut
constituent 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.
Plutôt que de mémoriser toutes ces différences subtiles, les développeurs peuvent utiliser
Bibliothèque JavaScript web-vitals sur
mesure le FID, qui gère ces différences à votre place (si possible, notez que le problème d'iFrame n'est pas couvert):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
Reportez-vous au code source
onFID()
pour obtenir un exemple complet de la façon de mesurer le FID en JavaScript.
Analyser les données FID et créer des rapports les concernant
En raison de la variation attendue des valeurs FID, il est essentiel que lors de la création de rapports sur Le FID, vous examinez la distribution des valeurs et concentrez-vous sur les centiles les plus élevés.
Bien que choisissez centile pour l'ensemble des Les seuils des métriques Core Web Vitals sont le 75e. Pour le FID en particulier, recommandent d'examiner les 95e à 99e centiles, car ils correspondent aux les premières expériences particulièrement mauvaises des utilisateurs avec votre site. Il va les points à améliorer.
Ce principe s'applique même si vous segmentez vos rapports par catégorie ou par type d'appareil. Pour Par exemple, si vous générez des rapports distincts pour les ordinateurs et les mobiles, la valeur du FID que vous qui intéressent le plus les utilisateurs d'ordinateurs doivent se situer entre les 95e et 99e centiles, et la valeur FID qui vous intéresse le plus sur mobile doit être comprise entre 95 et 99. d'utilisateurs sur mobile.
Améliorer le FID
Un guide complet sur l'optimisation du FID est disponible pour vous présenter des techniques permettant d'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 elles peuvent apparaître sous forme d'améliorations ou de 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 concernant ces métriques, vous pouvez les envoyer dans le groupe Google "web-vitals-feedback".