Étude de cas sur les modifications mises en œuvre par GoDaddy pour améliorer les performances des sites Web de millions de sites, ce qui leur a permis d'obtenir de bons scores PageSpeed Insights et Core Web Vitals.
GoDaddy est la plus grande plate-forme de services pour les entrepreneurs du monde entier. Nous avons pour mission d'aider notre communauté mondiale de plus de 20 millions de clients (et d'entrepreneurs du monde entier) en leur fournissant l'aide et les outils nécessaires pour se développer en ligne.
En 2019, GoDaddy a lancé Websites + Marketing pour fournir des outils et des services faciles à utiliser, afin d'aider les propriétaires d'entreprise à atteindre leurs objectifs. L'équipe Websites + Marketing intègre la création de sites Web à des outils de marketing et d'e-commerce et les associe à des conseils de pointe pour aider les clients à réussir leurs nouvelles activités.
Depuis le lancement de Websites + Marketing, les performances ont joué un rôle important dans le produit et ont fait l'objet d'une surveillance et d'un travail actifs. Dans cet article, nous allons étudier le parcours de GoDaddy, de l'utilisation des tests de performance en laboratoire à l'utilisation de données réelles avec les métriques Core Web Vitals, ainsi que la série d'améliorations apportées au produit pour obtenir un taux de réussite très élevé pour les sites de nos clients.
Suivre les performances avec Lighthouse
Nous nous sommes appuyés sur les données Lighthouse pour suivre les performances. Chaque fois qu'un site Web est publié sur la plate-forme, nous mesurons ses performances à l'aide de notre outil interne appelé "Lighthouse4u", qui fournit le service Google Lighthouse à l'adresse https://github.com/godaddy/lighthouse4u. Nous avions ainsi une bonne idée des performances générales des sites dans un paramètre de test.
Les millions de sites que nous hébergeons sur notre plate-forme offrent un large éventail de fonctionnalités et de contenus. Il était donc important de combiner les données de performances avec les métadonnées relatives à chaque site testé (comme le modèle utilisé, le type de widget affiché, etc.). Cela nous a permis de tirer des conclusions sur les fonctionnalités du site Web qui avaient de faibles performances, tout en nous donnant des indications sur les points à améliorer.
Par exemple, cela nous a permis d'identifier que la fenêtre modale pop-up avait un impact négatif sur la vitesse des pages. En effet, les sites dotés de cette fonctionnalité ont enregistré un score inférieur de 12 points par rapport aux autres. Après avoir mis à jour le code pour différer le chargement de JavaScript, nous avons amélioré notre score Lighthouse de 2 points. Nous avons pu appliquer ces connaissances à d'autres fonctionnalités, comme la "bannière pour les cookies", qui s'affiche peu de temps après le chargement de la page.
En plus d'examiner les sites problématiques en fonction de leurs fonctionnalités, nous avons analysé le bundle JavaScript et constaté qu'une grande partie de sa taille provenait de dépendances externes (immutable.js et brouillon.js). Nous avons réduit la taille du bundle en restructurant les consommateurs en dépendances de chargement différé à la demande. Cela a entraîné une baisse de plus de 50% de la taille du bundle JavaScript commun, qui est passée de plus de 200 Ko à environ 90 Ko (miniature). La taille réduite du bundle a permis au navigateur de charger des éléments externes et d'exécuter des scripts critiques plus tôt dans le cycle de vie du chargement initial du site, ce qui s'est traduit par des gains dans le Largest Contentful Paint (LCP) et le First Input Delay (FID).
Grâce à nos efforts continus, le score Lighthouse moyen du site client est passé d'environ 40 points en novembre 2020 à plus de 70 points en mai 2021. Cependant, toutes nos tentatives n'ont pas toutes fonctionné et nous avons parfois été surpris de voir que les résultats n'étaient pas toujours cohérents entre les tests effectués dans des environnements locaux et ceux obtenus sur le terrain. Les résultats des ateliers se sont révélés très utiles, mais le moment était venu de nous concentrer sur les expériences utilisateur réelles observées sur le terrain.
Suivre les données utilisateur réelles avec les métriques Core Web Vitals
Après avoir ajouté la bibliothèque web-vitals aux sites de nos clients, nous avons pu mesurer des données sur des appareils réels pour des visiteurs réels, lorsque le matériel, la vitesse du réseau et les interactions utilisateur (comme le défilement ou les clics) ne sont pas à la même base, comme dans un atelier avec Lighthouse. C'était un grand pas dans la bonne direction, car nous disposions désormais de données représentatives de l'expérience des visiteurs de notre site Web.
Se concentrer sur notre maillon faible: le CLS (Cumulative Layout Shift)
L'analyse de nouvelles données nous a donné une nouvelle perspective sur ce qu'il fallait faire pour améliorer la vitesse du site Web. En raison des efforts déployés pour améliorer le score Lighthouse, notre LCP au 75e centile était de 860 ms et notre FID au même seuil était inférieur à 10 ms. Nous avons donc enregistré un taux de réussite élevé pour ces métriques sur les sites de nos clients: 78% et 98%, respectivement. Toutefois, les chiffres du CLS (Cumulative Layout Shift) sont assez différents de ceux auxquels nous étions habitués avec Lighthouse. Notre CLS au 75e centile était de 0,17 (au-dessus du seuil de 0,1 pour réussir), et notre taux de réussite n'était donc que de 47% sur l'ensemble de nos sites.
Cette métrique a fait baisser notre taux de réussite global à 40 %. Nous avons donc décidé de nous fixer un objectif ambitieux de passer à plus de 60% d'ici la fin du mois d'août 2021. Pour ce faire, nous devrions nous concentrer sur le CLS.
Dans la vie réelle, les utilisateurs interagissent avec la page et font défiler le contenu au-dessus de la ligne de flottaison, ce que le rapport Core Web Vitals enregistre mieux. En raison de la variabilité de la manière dont les utilisateurs interagissent avec le site lors de son chargement initial, le CLS était différent des données de test et réelles.
Comment réussir toutes les métriques Core Web Vitals
Pour améliorer les performances, il faut procéder par essais et erreurs, et chaque tentative ne fonctionne pas toujours comme prévu. Toutefois, voici quelques améliorations qui nous ont aidés à atteindre nos objectifs.
La réservation d'espace pour le chargement des images a considérablement amélioré notre score CLS, car elle empêche le déplacement du contenu situé sous les images. Nous avons utilisé la propriété CSS aspect-ratio pour résoudre ce problème dans les navigateurs compatibles. Pour ceux qui ne le font pas, nous avons chargé une image d'espace réservé transparent qui a été mise en cache et dont la taille ne dépasse que quelques octets. Elle se charge donc presque instantanément.
Ce comportement d'image générique nous a permis de précalculer la hauteur finale de l'image lors du rendu côté serveur, en fonction de la largeur de la fenêtre d'affichage et du format de l'image. Il en résulte un balisage HTML avec un espace vertical réservé à l'image finale. Cette amélioration est particulièrement visible sur les appareils mobiles, car les images sont affichées sur l'ensemble de la fenêtre d'affichage mobile.
Certains composants présents sur les sites de nos clients comportent du contenu dynamique (par exemple, une liste d'avis de clients externes) et ne peuvent pas être convertis en CSS pur pour bénéficier des avantages du rendu côté serveur en termes de performances. Il s'agit de zones difficiles à améliorer, car le contenu (et donc la hauteur) varie. Dans ce cas, nous avons encapsulé le composant dans un conteneur avec une min-height appliquée, prédéterminée d'après l'observation de la hauteur moyenne de chacun des composants spécifiques. min-height est supprimé une fois l'affichage du composant dynamique interne terminé. Bien qu'elle ne soit pas parfaite, cette solution nous a permis de réduire considérablement le décalage de mise en page.
Tout en nous concentrant sur les améliorations du CLS, nous avons continué à travailler sur le LCP. Sur de nombreux sites Web, les images sont le principal coupable au LCP et, pour nous, c'était un domaine d'amélioration évident. Nous avions amélioré les images à chargement différé à l'aide de IntersectionObserver, mais nous nous sommes rendu compte que la taille d'image n'était pas définie de la manière la plus optimale pour chaque point d'arrêt (mobile, tablette, ordinateur de bureau, grand ordinateur). Nous avons donc mis à jour notre code de génération d'images pour limiter et ajuster les images par point d'arrêt, puis nous avons à nouveau ajusté la résolution en fonction de la densité de pixels. Par exemple, cela a permis de réduire la taille d'une grande image spécifique de 192 Ko à 102 Ko.
Pour afficher rapidement les sites Web sur les appareils avec une connexion réseau de mauvaise qualité, nous avons ajouté du code permettant de réduire de façon dynamique la qualité des images en fonction de la vitesse de connexion. Pour ce faire, utilisez la propriété downlink renvoyée par navigator.connection. Nous appliquons des paramètres de requête basés sur les URL pour réduire la qualité de l'image via notre API de composants en fonction de ces conditions de réseau.
Un certain nombre de sections des sites de nos clients sont chargées dynamiquement. Étant donné que nous savons quelles sections seront affichées sur un site donné lors de sa publication, nous avons utilisé l'indice de ressource rel=preconnect pour initialiser la connexion et les handshakes nécessaires à l'avance. Nous utilisons également les indications de ressources pour charger rapidement les polices et d'autres ressources importantes.
Lors de la création de leurs sites, les clients ajoutent diverses sections pouvant comporter des scripts intégrés pour permettre différentes fonctionnalités. L'intégration de ces scripts sur l'ensemble de la page HTML n'est pas toujours optimale pour les performances. Nous avons décidé d'externaliser ces scripts pour permettre au navigateur de charger et d'analyser leur contenu de manière asynchrone. Les nouveaux scripts externalisés peuvent également être partagés entre les pages. Cela a permis d'obtenir des gains de performances supplémentaires grâce à la mise en cache du navigateur et du CDN. Nous avons intégré les scripts essentiels afin que le navigateur puisse les analyser et les exécuter plus rapidement.
Résultats
Nos efforts concernant le CLS ont porté leurs fruits. Notre taux de réussite dans le rapport Core Web Vitals est passé d'environ 40% à près de 70 %, soit une amélioration de 75 %.
Lorsque les utilisateurs reviennent sur notre plate-forme pour effectuer des mises à jour et publier à nouveau leurs sites, ils bénéficient des dernières améliorations des performances. Par conséquent, le nombre de sites ayant réussi le test des Core Web Vitals augmente régulièrement, comme le montre le graphique ci-dessous:
Conclusions
L'identification des axes d'amélioration des performances et le suivi efficace des progrès dépendent essentiellement des outils de mesure utilisés. Bien que Lighthouse ait été utile pour mesurer les performances au-dessus de la ligne de flottaison dans un "paramètre de test", il n'a pas permis de capturer avec précision les problèmes de performances provenant uniquement des interactions des utilisateurs (comme le défilement de la page).
Le suivi des Core Web Vitals réels avec des métadonnées nous a permis de visualiser, de cibler et de mesurer l'impact de nos améliorations. L'amélioration des scores Core Web Vitals a permis à l'équipe d'identifier et de remplacer les modèles non performants détectés dans notre codebase. Parfois, les changements prometteurs n'ont pas eu l'impact attendu, d'autres fois le contraire. Le monde n'est pas encore intact, alors il faut continuer à essayer.