Tester le délai de première entrée dans le rapport UX Chrome

L'objectif du rapport d'expérience utilisateur Chrome est d'aider la communauté Web à comprendre la distribution et l'évolution des performances réelles des utilisateurs. À ce jour, nous nous sommes concentrés sur les métriques de peinture et de chargement de page telles que le First Contentful Paint (FCP) et Onload (OL), qui nous ont aidés à comprendre les performances visuelles des sites Web pour les utilisateurs. À partir de la version de juin 2018, nous testons une nouvelle métrique axée sur l'utilisateur qui se concentre sur l'interactivité des pages Web : le First Input Delay (FID). Cette nouvelle métrique nous permettra de mieux comprendre à quel point les sites Web sont responsifs vis-à-vis des entrées utilisateur.

Le FID a récemment été mis à disposition dans Chrome en tant que phase d'évaluation de l'origine, ce qui signifie que les sites Web peuvent tester cette nouvelle fonctionnalité de plate-forme Web. De même, le FID sera disponible dans le rapport UX Chrome en tant que métrique expérimentale, ce qui signifie qu'il sera disponible pendant toute la durée du test de l'origine dans un espace de noms "expérimental" distinct.

Comment le FID est-il mesuré ?

Qu'est-ce qu'un FID exactement ? Voici ce qui est défini dans l'article de blog sur le First Input Delay:

Le délai avant la première entrée (FID) mesure le temps écoulé entre le moment où un utilisateur interagit pour la première fois avec votre site (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 est en mesure de répondre à cette interaction.

Animation montrant comment un thread principal occupé retarde la réponse à une interaction utilisateur.

C'est comme si vous cliquiez entre le moment où quelqu'un sonne à la porte et celui où il répond à la porte. Plusieurs raisons peuvent expliquer cette lenteur. Par exemple, la personne se trouve peut-être loin de la porte ou ne peut pas se déplacer rapidement. De même, les pages Web peuvent être occupées par d'autres tâches ou l'appareil de l'utilisateur peut être lent.

Explorer le FID dans le rapport UX Chrome

Avec un mois de données FID provenant de millions d'origines, il existe déjà une multitude d'insights intéressants à découvrir. Étudions quelques requêtes montrant comment extraire ces insights du rapport d'expérience utilisateur Chrome sur BigQuery.

Commençons par interroger le pourcentage d'expériences FID rapides pour developers.google.com. Une expérience rapide est celle où le FID est inférieur à 100 ms. Conformément aux recommandations RAIL, si le délai est de 100 ms ou moins, l'utilisateur doit avoir l'impression que l'expérience est instantanée.

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
  origin = 'https://developers.google.com'

Les résultats montrent que 95 % des expériences FID sur cette origine sont perçues comme instantanées. Cela semble très intéressant, mais comment se compare-t-il à toutes les origines de l'ensemble de données ?

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid

Les résultats de cette requête montrent que 84% des expériences FID sont inférieures à 100 ms. developers.google.com est donc au-dessus de la moyenne.

Essayons ensuite de découper ces données pour voir s'il existe une différence entre le pourcentage de FID rapide sur ordinateur et sur mobile. Une hypothèse est que les appareils mobiles ont des valeurs FID plus lentes, peut-être en raison d'un matériel plus lent que les ordinateurs de bureau. Si le processeur est moins puissant, il peut être plus occupé pendant une période plus longue, ce qui peut entraîner des expériences FID plus lentes.

SELECT
  form_factor.name AS form_factor,
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
  form_factor
form_factor fast_fid
desktop 96,02 %
téléphone 79,90 %
tablette 76,48%

Les résultats corroborent notre hypothèse. Les ordinateurs présentent une densité cumulative plus élevée d'expériences FID rapides que les téléphones et les tablettes. Pour comprendre pourquoi ces différences existent (par exemple, les performances du processeur), vous devez effectuer des tests A/B qui ne relèvent pas du rapport d'expérience utilisateur Chrome.

Maintenant que nous avons vu comment déterminer si une origine présente des expériences FID rapides, examinons deux origines qui fonctionnent très bien.

Exemple 1 : http://secretlycanadian.com

Pellicule WebPageTest de secretlycanadian.com

Cette origine enregistre 98% d'expériences FID inférieures à 100 ms. Comment y parvient-elle ? En analysant la façon dont elle est créée dans WebPageTest, nous pouvons voir qu'il s'agit d'une page WordPress très chargée d'images, mais elle contient 168 ko de code JavaScript qui s'exécute en environ 500 ms sur notre machine de laboratoire. Ce n'est pas beaucoup de code JavaScript selon l'archive HTTP, qui place cette page dans le 28e percentile.

Cascade AWebPageTest de secretlycanadian.com

La barre rose qui s'étend de 2,7 à 3 secondes correspond à la phase d'analyse du code HTML. Pendant ce temps, la page n'est pas interactive et semble visuellement incomplète (voir "3,0 s" dans la pellicule ci-dessus). Ensuite, toutes les tâches longues qui doivent être traitées sont divisées pour s'assurer que le thread principal reste inactif. Les lignes roses de la ligne 11 montrent comment le travail JavaScript est réparti en rafales rapides.

Exemple 2 : https://www.wtfast.com

Pellicule WebPageTest de wtfast.com

Cette origine offre 96% d'expériences FID instantanées. Il charge 267 Ko de code JavaScript (38e centile dans l'archive HTTP) et le traite pendant 900 ms sur la machine de l'atelier. La pellicule montre que la page met environ cinq secondes à peindre l'arrière-plan et environ deux secondes de plus à peindre le contenu.

Cascade WebPageTest de wtfast.com

Le plus intéressant des résultats est qu'aucun élément interactif n'est visible lorsque le thread principal est occupé pendant trois à cinq secondes. C'est en fait la lenteur du FCP de cette page qui améliore le FID. Ceci est un bon exemple de l'importance d'utiliser de nombreuses métriques pour représenter l'expérience utilisateur.

Commencer l'exploration

Pour en savoir plus sur le FID, regardez l'épisode de cette semaine du rapport The State of the Web:

La disponibilité du FID dans le rapport d'expérience utilisateur Chrome nous permet d'établir une référence pour les expériences d'interactivité. Grâce à cette référence, nous pouvons observer son évolution dans les prochaines versions ou comparer des origines individuelles. Si vous souhaitez commencer à collecter le FID dans les mesures de champ de votre propre site, inscrivez-vous à l'essai d'origine en accédant à bit.ly/event-timing-ot et sélectionnez la fonctionnalité "Durée de l'événement". Et bien sûr, commencez à explorer l'ensemble de données pour obtenir des insights intéressants sur l'état de l'interactivité sur le Web. Il s'agit toujours d'une métrique expérimentale. N'hésitez donc pas à nous faire part de vos commentaires et à partager votre analyse sur le groupe de discussion du rapport d'expérience utilisateur Chrome ou sur @ChromeUXReport sur Twitter.