Étude de cas sur les modifications apportées par l'équipe Web de YouTube pour améliorer les performances, augmenter les taux de conformité aux Core Web Vitals et améliorer les métriques commerciales clés.
L'équipe Chrome parle souvent 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 de l'appareil au moment où les utilisateurs en ont le plus besoin. Le dogfooding fait partie de la culture de Google. L'équipe Chrome s'est donc associée à YouTube pour partager les leçons apprises au fil du temps dans une nouvelle série intitulée "Créer un meilleur Web". Dans la première partie, nous verrons comment YouTube a conçu une expérience Web plus rapide.
Sur YouTube, les performances correspondent à la rapidité avec laquelle les vidéos et les autres contenus (comme les recommandations et les commentaires) se chargent sur les pages Web. Les performances sont également mesurées par la rapidité avec laquelle YouTube répond aux interactions des utilisateurs, comme la recherche, le contrôle du lecteur, les "J'aime" et les partages.
Les marchés en pleine croissance, tels que 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, il est essentiel de garantir une expérience rapide et fluide.
Afin d'offrir une expérience inclusive à tous les utilisateurs, YouTube a entrepris d'améliorer les métriques de performances telles que Core Web Vitals grâce au chargement différé et à la modernisation du code.
Améliorer les métriques Core Web Vitals
Pour identifier les axes d'amélioration, l'équipe YouTube a utilisé le rapport d'expérience utilisateur Chrome afin de voir comment les utilisateurs réels utilisaient les pages de résultats de recherche et de visionnage de vidéos sur mobile dans le terrain. Il s'est rendu compte que ses métriques Core Web Vitals avaient beaucoup de marge de progression, avec une métrique Largest Contentful Paint (LCP) qui s'élevait à 4 à 6 secondes dans certains cas. Ce chiffre était bien supérieur à l'objectif de 2,5 secondes.
Pour identifier les axes d'amélioration, il a utilisé Lighthouse pour auditer les pages de lecture YouTube. Il a ainsi découvert un score Lighthouse (laboratoire) faible, avec un First Contentful Paint (FCP) de 3,5 secondes et un LCP de 8,5 secondes.
Pour optimiser le FCP et le LCP, l'équipe YouTube a mené plusieurs tests, qui ont débouché sur deux grandes découvertes.
La première découverte a été la possibilité d'améliorer les performances en déplaçant le code HTML du composant Video Player au-dessus du script qui le rend interactif. Les tests en laboratoire ont indiqué que cela pouvait améliorer 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 de l'affiche de l'élément
<video>et non les images du flux vidéo lui-même. En général, YouTube optimise le temps de lecture des vidéos le plus court. Pour améliorer le LCP, l'équipe a donc commencé à optimiser la vitesse de diffusion de l'image poster. Il a testé plusieurs variantes d'images d'affiches et a choisi celle qui a obtenu le meilleur score lors des tests utilisateur. Grâce à ce travail, le FCP et le LCP ont tous deux enregistré une amélioration notable. Le LCP du champ est passé de 4,6 secondes à 2,0 secondes.
Bien que ces optimisations aient amélioré le LCP, l'équipe a estimé que la définition actuelle de la métrique LCP ne capturait pas complètement, du point de vue de l'utilisateur, le moment où le "contenu principal" de la page était chargé, ce qui est l'objectif du LCP.
Pour répondre à ces préoccupations, des membres de l'équipe YouTube ont collaboré avec des membres de l'équipe Chrome afin d'explorer les moyens d'améliorer la métrique LCP pour répondre à leur cas d'utilisation. Après avoir examiné la faisabilité et l'impact de quelques options, les équipes ont abouti à une proposition consistant à considérer le temps de peinture du premier frame d'un élément vidéo comme candidat au LCP.
Une fois ce changement déployé dans Chrome, l'équipe YouTube sera ravie de poursuivre son travail d'optimisation pour le LCP. La version mise à jour de la métrique permettra à ces optimisations d'avoir un impact plus direct sur l'expérience des utilisateurs réels.
Modularisation avec le chargement différé
Les pages YouTube contenaient de nombreux modules qui étaient chargés très rapidement. Pour optimiser le rendu de plus de 50 composants, l'équipe a créé un mappage de composants vers des modules JavaScript qui indique au client les modules à charger. En marquant les composants comme inactifs, les modules JS se chargent plus tard, ce qui réduit le temps de chargement initial de la page et la quantité de code JavaScript inutilisé envoyée au client.
Toutefois, après l'implémentation du chargement différé, l'équipe a remarqué un effet cascade selon lequel les composants chargés 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és dans une seule requête réseau. Les résultats ont été une amélioration de la vitesse de la page, une réduction du temps d'analyse JavaScript et, finalement, de meilleurs temps de rendu initial.
Gestion de l'état des composants
YouTube rencontrait des problèmes de performances en raison de ses commandes de lecteur, en particulier sur les appareils plus anciens. 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é surcomposé 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 exécutions de tests de performances en laboratoire. À mesure que de nouveaux contrôles étaient ajoutés au fil du temps, le modèle de contrôle décentralisé entraînait souvent des dépendances circulaires et des fuites de mémoire, ce qui avait un impact négatif sur les performances de la page de lecture.
Pour résoudre les problèmes dus au contrôle décentralisé, l'équipe a mis à jour l'interface utilisateur du lecteur pour synchroniser toutes les mises à jour, en refactorisant le lecteur en un composant de premier niveau qui transmettait les données à ses enfants. Cela garantissait un seul cycle de mise à jour (rendu) de l'UI pour tout changement d'état, ce qui éliminait les mises à jour en série. L'événement de déplacement tactile de la barre de progression du nouveau lecteur ne nécessite plus de recalculs de style lors de son exécution JavaScript et ne prend désormais que 25% du temps de l'ancien lecteur.
Cette modernisation du code a également permis d'améliorer les performances, par exemple en termes de temps de chargement des vidéos sur les anciens appareils, de nombre de lectures abandonnées et de nombre d'erreurs non fatales.
Résultats et optimisations
Grâce à l'investissement 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 dépassent désormais les seuils des métriques Core Web Vitals sur le terrain. Sur ordinateur, le LCP des ateliers pour la page de lecture est passé de 4,6 secondes à 1,6 seconde. Les performances d'interaction et de rendu du site, en particulier dans le lecteur vidéo YouTube, sont jusqu'à 75% plus rapides qu'auparavant.
Les améliorations apportées aux performances de YouTube sur le Web au cours de l'année écoulée ont également permis d'améliorer les métriques métier, y compris la durée de visionnage et le nombre d'utilisateurs actifs par jour. Compte tenu du succès de ces efforts, nous prévoyons de continuer à explorer d'autres moyens d'optimisation à l'avenir.
Nous remercions tout 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.