Étude de cas sur les modifications apportées par l'équipe Web de YouTube pour améliorer les performances, augmenter le taux de réussite des Core Web Vitals et améliorer les métriques commerciales clés.
L'équipe Chrome parle souvent de l'idée de "créer un Web meilleur", mais qu'est-ce que cela signifie ? Les expériences Web doivent être rapides, accessibles et utiliser les fonctionnalités des appareils au moment où les utilisateurs en ont le plus besoin. La version dogfood fait partie de la culture de Google. C'est pourquoi l'équipe Chrome s'est associée à YouTube pour partager les enseignements tirés en cours de route dans une nouvelle série intitulée "Bâtir un Web plus efficace". Dans la première partie de la série, nous allons voir comment YouTube a amélioré l'expérience Web.
Bâtir un Web plus rapide
Chez YouTube, les performances concernent la vitesse de chargement des vidéos et d'autres contenus (tels que les recommandations et les commentaires) sur les pages Web. Les performances sont également mesurées par la rapidité avec laquelle YouTube répond aux interactions des utilisateurs telles que la recherche, les commandes du lecteur, les "J'aime" et les partages.
Les marchés en plein essor, comme le Brésil, l'Inde et l'Indonésie sont importants pour le Web mobile YouTube. Étant donné que de nombreux utilisateurs de ces régions disposent d'appareils plus lents et d'une bande passante réseau limitée, garantir une expérience rapide et fluide est l'objectif essentiel.
Afin d'offrir une expérience inclusive pour tous les utilisateurs, YouTube a décidé d'améliorer les métriques de performances telles que les Core Web Vitals grâce au chargement différé et à la modernisation du code.
Améliorer les Core Web Vitals
Pour identifier les points à améliorer, l'équipe YouTube s'est appuyée sur le rapport d'expérience utilisateur Chrome pour savoir comment des utilisateurs réels voyaient des vidéos et des pages de résultats de recherche sur mobile sur le terrain. L'équipe a réalisé que ses métriques Core Web Vitals pouvaient beaucoup être améliorées, la métrique Largest Contentful Paint (LCP) s'étant produite dans certains cas en 4 à 6 secondes. Ce nombre était nettement supérieur à l'objectif de 2,5 secondes.
Pour identifier les points à améliorer, l'équipe s'est tournée vers Lighthouse pour réaliser un audit des pages de lecture YouTube, révélant un faible score Lighthouse (lab) avec un FCP (First Contentful Paint) de 3,5 secondes et un LCP de 8,5 secondes.
Pour optimiser le FCP et le LCP, l'équipe YouTube s'est plongée dans plusieurs tests, ce qui a permis de faire deux découvertes majeures.
Elle a tout d'abord découvert qu'elle pouvait améliorer les performances en déplaçant le code HTML du lecteur vidéo au-dessus du script qui le rend interactif. Les tests de laboratoire ont indiqué que cela pourrait améliorer à la fois le FCP et le LCP de 4,4 secondes à 1,1 seconde.
La deuxième découverte a été que le LCP ne prend en compte que les images poster de l'élément
<video>et non les images du flux vidéo lui-même. YouTube optimise généralement la vidéo pour qu'elle démarre le plus rapidement possible. Pour améliorer le LCP, l'équipe a donc également commencé à optimiser la vitesse de diffusion de l'image poster. Elle a testé quelques variantes d'images poster et a choisi celle qui avait obtenu les meilleurs résultats lors des tests utilisateur. Grâce à ce travail, le FCP et le LCP ont montré une amélioration significative, le LCP de champ est passé de 4,6 secondes à 2 secondes.
Même si ces optimisations ont permis d'améliorer le LCP, l'équipe a estimé que la définition actuelle de la métrique LCP n'était pas complètement capturée, du point de vue de l'utilisateur, lorsque le "contenu principal" de la page était chargé, ce qui est l'objectif du LCP.
Pour répondre à ces préoccupations, les membres de l'équipe YouTube ont collaboré avec les membres de l'équipe Chrome afin de déterminer comment améliorer la métrique LCP pour mieux répondre à leurs besoins. Après avoir examiné la faisabilité et l'impact de quelques options, les équipes ont élaboré une proposition visant à considérer le temps de rendu de la première image d'un élément vidéo comme candidat au LCP.
Lorsque ce changement sera déployé dans Chrome, l'équipe YouTube sera ravie de continuer à optimiser le LCP. La nouvelle version de cette métrique signifie que ces optimisations auront un impact plus direct sur l'expérience utilisateur réelle.
Modularisation avec chargement différé
Les pages YouTube contenaient de nombreux modules qui étaient chargés rapidement. Pour optimiser le rendu de plus de 50 composants, l'équipe a créé un composant pour le mappage de module JS qui indiquerait au client les modules à charger. Si vous marquez les composants comme inactifs, les modules JS se chargeraient ultérieurement, ce qui réduira le temps de chargement initial de la page et la quantité de code JavaScript inutilisé envoyé au client.
Toutefois, après la mise en œuvre du chargement différé, l'équipe a remarqué un effet de cascade : les composants à chargement différé et leurs dépendances se chargeaient à des moments non optimaux.
Pour résoudre ce problème, l'équipe a déterminé l'ensemble minimal de composants requis dans une vue et les a regroupées dans une seule requête réseau. Cela a permis d'améliorer la vitesse des pages, la réduction du temps d'analyse JavaScript et, au final, le délai d'affichage initial.
Gestion de l'état entre les composants
YouTube rencontrait des problèmes de performances en raison des commandes du lecteur, en particulier sur les anciens appareils. L'analyse du code a montré que le lecteur, qui permet aux utilisateurs de contrôler des fonctionnalités telles que la vitesse de lecture et la progression, avait été subdivisé au fil du temps.
Chaque événement de déplacement tactile de la barre de progression a déclenché deux recalculs de style supplémentaires et a pris 21,17 ms lors des tests de performance dans l'atelier. À mesure que de nouveaux contrôles étaient ajoutés au fil du temps, le modèle de contrôle décentralisé provoquait souvent des dépendances circulaires et des fuites de mémoire, avec un impact négatif sur les performances des pages de lecture.
Pour résoudre les problèmes dus au contrôle décentralisé, l'équipe a mis à jour l'UI du lecteur afin de synchroniser toutes les mises à jour, en refactorisant le lecteur en un composant de niveau supérieur qui transmettrait des données à ses enfants. Cela a permis de garantir un seul cycle de mise à jour (rendu) de l'UI pour tout changement d'état, éliminant ainsi les mises à jour en chaîne. L'événement de déplacement tactile de la barre de progression du joueur ne comporte pas de recalcul de style lors de son exécution JavaScript et ne nécessite désormais que 25% du temps que l'ancien lecteur utilise.
Cette modernisation du code a également entraîné des améliorations des performances supplémentaires, telles que l'amélioration du temps de chargement des montres sur les anciens appareils, la diminution du nombre de lectures abandonnées et du nombre d'erreurs non fatales.
Conclusion
Grâce aux investissements de YouTube en termes de performances, les pages de lecture se chargent beaucoup plus rapidement. En effet, 76% des URL des sites Web mobiles de YouTube atteignent désormais les seuils des métriques Core Web Vitals. Sur les ordinateurs, le LCP de l'atelier pour la page de lecture est passé de 4,6 secondes à 1,6 seconde. En termes d'interaction et de performances d'affichage sur le site, en particulier avec le lecteur vidéo YouTube, le temps consacré à l'exécution de JavaScript est jusqu'à 75% inférieur à ce qu'il était auparavant.
Les performances de YouTube sur le Web au cours de l'année écoulée ont également permis d'améliorer les métriques commerciales, y compris la durée de visionnage et le nombre d'utilisateurs actifs par jour. Au vu du succès de ces initiatives, nous prévoyons de continuer à explorer d'autres méthodes d'optimisation à l'avenir.
Dans la deuxième partie de cette série, intitulée "Créer un Web accessible", vous découvrirez comment YouTube a rendu son site Web plus accessible aux utilisateurs de lecteurs d'écran.
Nous remercions particulièrement Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra, ainsi que les équipes YouTube et Chrome pour leur contribution à ce travail.