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 comment les sites Web responsifs répondent aux 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 que le FID exactement ? Voici comment il est défini dans l'article de blog annonçant 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 mesurer le temps écoulé entre le moment où vous sonnez à la porte de quelqu'un et celui où il vous répond. 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, de nombreux insights intéressants sont déjà à découvrir. Examinons quelques requêtes qui montrent comment extraire ces insights du rapport sur l'expérience utilisateur Chrome dans 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 vraiment bien, 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. L'ordinateur de bureau présente une densité cumulée plus élevée d'expériences FID rapides que les facteurs de forme de téléphone et de tablette. 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 sur l'expérience utilisateur Chrome.

Maintenant que nous avons vu comment déterminer si une origine offre des expériences FID rapides, examinons quelques origines qui enregistrent de très bonnes performances.

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, ce 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 enregistre 96% d'expériences FID instantanées. Il charge 267 ko de code JavaScript (38e percentile dans HTTP Archive) 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. C'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 la semaine de 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 sur le terrain de votre propre site, inscrivez-vous au test de l'origine sur bit.ly/event-timing-ot et sélectionnez la fonctionnalité de chronométrage des événements. 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.