Étude de cas sur les modifications apportées par GoDaddy pour améliorer les performances de millions de sites Web, 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 au monde pour les entrepreneurs du monde entier. Notre mission est de donner à notre communauté mondiale de plus de 20 millions de clients et d'entrepreneurs les outils et l'aide dont ils ont besoin pour se développer en ligne.
En 2019, GoDaddy a lancé Websites + Marketing avec l'objectif de proposer des outils et des services faciles à utiliser pour aider les propriétaires d'entreprises à atteindre leurs objectifs. 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 entreprises.
Depuis le lancement de Sites Web + Marketing, les performances ont été un élément important du produit, qui a été surveillé et travaillé activement. Dans cet article, nous allons retracer le parcours de GoDaddy, qui est passé des tests de performances en laboratoire à l'utilisation de données réelles avec 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 nommé "Lighthouse4u", qui fournit Google Lighthouse en tant que service (https://github.com/godaddy/lighthouse4u). Cela nous a donné une bonne indication des performances générales des sites dans un environnement de laboratoire.
Étant donné que les millions de sites que nous hébergeons sur notre plate-forme présentent un large éventail de fonctionnalités et de contenus, il était important de combiner les données de performances avec les métadonnées de chaque site testé (comme le modèle utilisé, le type de widgets affichés, etc.). Cela nous a permis de tirer des conclusions sur les fonctionnalités du site Web qui enregistrent des performances plus faibles, tout en nous indiquant où chercher des améliorations.
Par exemple, cela nous a permis de constater que le "pop-up modal" avait un impact négatif sur la vitesse de chargement des pages. Les sites qui utilisaient cette fonctionnalité avaient des performances 12 points inférieures à celles des sites qui ne l'utilisaient pas. Après avoir modifié le code pour différer le chargement du code JavaScript, nous avons amélioré notre score Lighthouse de deux points. Nous avons pu appliquer ces enseignements à d'autres fonctionnalités, comme la bannière de cookies qui s'affiche peu de temps après le chargement de la page.
En plus d'examiner les sites problématiques en fonction des fonctionnalités, nous avons analysé notre bundle JavaScript et constaté qu'une grande partie de sa taille provenait de dépendances externes (immutable.js et draft.js). Nous avons réduit la taille du bundle en restructurant les consommateurs pour charger les dépendances à la demande. La taille du bundle JavaScript commun a ainsi diminué de plus de 50 %, passant de plus de 200 Ko à environ 90 Ko (minimisé). La taille réduite du bundle a permis au navigateur de charger des composants externes et d'exécuter des scripts critiques plus tôt dans le cycle de vie initial du chargement du site, ce qui a entraîné des gains en termes de Largest Contentful Paint (LCP) et de First Input Delay (FID).
Grâce à nos efforts continus, le score Lighthouse moyen des sites client est passé d'environ 40 points en novembre 2020 à plus de 70 points en mai 2021. Cependant, toutes nos tentatives n'ont pas été couronnées de succès, et nous avons parfois été surpris de constater que les résultats n'étaient pas toujours cohérents entre ce qui était testé dans les environnements de test locaux et les résultats obtenus sur le terrain. Les résultats du laboratoire ont été très utiles, mais il était temps de se concentrer sur les expériences réelles des utilisateurs observées sur le terrain.
Suivre les données utilisateur réelles avec Core Web Vitals
Après avoir ajouté la bibliothèque web-vitals aux sites de nos clients, nous avons pu mesurer les données sur les appareils réels de visiteurs réels, où le matériel, la vitesse du réseau et les interactions utilisateur (comme le défilement ou les clics) ne sont pas à un niveau de référence cohérent comme dans un environnement de laboratoire à l'aide de 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 le plus faible: le CLS (Cumulative Layout Shift)
L'analyse de nouvelles données nous a permis d'avoir une nouvelle perspective sur ce qui devait être fait pour améliorer la vitesse du site Web. Grâce aux efforts déployés pour améliorer le score Lighthouse, notre LCP au 75e percentile était de 860 ms et notre FID au même seuil était inférieur à 10 ms. Nous avons donc obtenu un taux de réussite élevé pour ces métriques sur les sites de nos clients: 78% et 98%, respectivement. Cependant, les chiffres du décalage de mise en page cumulé (CLS) semblent très différents de ce à quoi nous étions habitués avec Lighthouse. Notre CLS au 75e percentile était de 0,17, au-dessus du seuil de 0,1 pour "réussir". Notre taux de réussite n'était donc que de 47% pour 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 pour atteindre ce chiffre à plus de 60% d'ici la fin août 2021. Pour ce faire, nous devons nous concentrer sur le CLS.
Dans la vraie vie, les utilisateurs interagissent avec la page et défilent au-delà du contenu "au-dessus de la ligne de flottaison", ce que les Core Web Vitals capturent mieux. En raison de la variabilité de la façon dont les utilisateurs interagissent avec le site lors de son chargement initial, le CLS différait des données de laboratoire et sur le terrain.
Réussir tous les Core Web Vitals
Pour améliorer les performances, vous devez procéder par essais et erreurs, et chaque tentative ne fonctionne pas toujours comme prévu. Voici toutefois quelques améliorations qui nous ont aidés à atteindre nos objectifs.
Réserver de l'espace pour le chargement des images a considérablement amélioré notre score CLS, car cela empêche le contenu situé sous les images de se déplacer. Nous avons utilisé la propriété CSS aspect-ratio pour résoudre ce problème dans les navigateurs compatibles. Pour les autres, nous avons chargé une image d'espace réservé transparente mise en cache de quelques octets seulement, ce qui permet un chargement presque instantané.
Ce comportement d'image générique nous a permis de précalculer la hauteur de l'image finale lors du rendu côté serveur, en fonction de la largeur de la fenêtre d'affichage et du format de l'image. Cela a entraîné une balise HTML avec un espace vertical réservé à l'image finale. L'amélioration était particulièrement visible sur les appareils mobiles, car les images sont affichées sur toute la largeur des vues mobiles.
Certains composants des sites de nos clients comportent du contenu dynamique (par exemple, une liste d'avis clients externes) et n'ont pas pu être convertis en CSS pur pour exploiter les avantages de performances du rendu côté serveur. Il est difficile d'améliorer les décalages de mise en page dans ces domaines, car le contenu (et donc la hauteur) varie. Dans ce cas, nous avons encapsulé le composant dans un conteneur avec un min-height appliqué, prédéterminé en fonction de l'observation de la hauteur moyenne de chacun des composants spécifiques. min-height est supprimé une fois le rendu 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 l'amélioration du CLS, nous avons continué à travailler sur le LCP. Sur de nombreux sites Web, les images sont le principal facteur contribuant au LCP. Pour nous, il s'agissait d'un axe d'amélioration évident. Nous avons amélioré le chargement différé des images à l'aide de IntersectionObserver, mais nous avons constaté que les tailles d'image n'étaient pas définies de manière optimale pour chaque point d'arrêt (mobile, tablette, ordinateur de bureau, grand ordinateur de bureau). Nous avons donc mis à jour notre code de génération d'images pour limiter et redimensionner les images par point d'arrêt, puis redimensionner la résolution en fonction de la densité de pixels. Par exemple, la taille d'une grande image spécifique est passée de 192 Ko à 102 Ko.
Pour afficher rapidement des sites Web sur des appareils dont la connexion réseau est mauvaise, nous avons ajouté du code permettant de réduire de manière 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 l'URL pour réduire la qualité de l'image via notre API d'éléments en fonction de ces conditions réseau.
Un certain nombre de sections des sites de nos clients sont chargées de manière dynamique. É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 poignées de main nécessaires à l'avance. Nous utilisons également des indices de ressources pour charger rapidement des polices et d'autres ressources importantes.
Lorsque les clients créent leurs sites, ils ajoutent différentes sections qui peuvent comporter des scripts intégrés pour permettre différentes fonctionnalités. L'intégration de ces scripts dans 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 le contenu des scripts de manière asynchrone. Les scripts nouvellement externalisés peuvent également être partagés entre les pages. Cela a permis d'améliorer les performances grâce à la mise en cache du navigateur et du CDN. Nous avons conservé les scripts critiques en ligne afin que le navigateur puisse les analyser et les exécuter plus rapidement.
Résultats
Nous avons vu les résultats de nos efforts sur le CLS : notre taux de réussite aux 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 mettre à jour et publier à nouveau leurs sites, ils bénéficient des dernières améliorations de performances. Par conséquent, le nombre de sites "répondant aux Core Web Vitals" a augmenté régulièrement, comme le montre le graphique ci-dessous:
Conclusions
Identifier les axes d'amélioration des performances et suivre la progression dépend fortement des outils de mesure utilisés. Bien que Lighthouse soit utile pour mesurer les performances au-dessus de la ligne de flottaison dans un "environnement de laboratoire", il ne capturait pas précisément les problèmes de performances qui ne survenaient qu'en raison des interactions des utilisateurs (par exemple, le défilement de la page).
Le suivi des Core Web Vitals réels à l'aide de métadonnées nous a permis de visualiser, de cibler et de mesurer l'impact de nos améliorations. Le processus d'amélioration des scores Core Web Vitals a permis à l'équipe d'identifier et de remplacer les modèles non performants trouvés dans notre codebase. Parfois, des changements prometteurs n'ont pas eu l'impact escompté, et parfois, c'est l'inverse. Le monde n'est pas parfait, alors vous devez continuer à essayer.