L'équipe Web de Zalando a constaté que l'intégration de Lighthouse CI permettrait une approche proactive des performances, avec des vérifications d'état automatisées capables de comparer le commit actuel à la branche principale pour éviter les régressions de performances.
Avec plus de 35 millions de clients actifs, Zalando est la première plate-forme de mode en ligne d'Europe. Dans cet article, nous expliquons pourquoi nous avons commencé à utiliser Lighthouse CI, la facilité d'implémentation et les avantages pour notre équipe.
Chez Zalando, nous connaissons le lien entre les performances des sites Web et les revenus. Par le passé, nous avons testé l'impact d'une augmentation artificielle du temps de chargement des pages de catalogue sur les taux de rebond, les taux de conversion et les revenus par utilisateur. Les résultats ont été clairs. Une amélioration de 100 millisecondes du temps de chargement des pages s'est traduite par une augmentation de l'engagement, avec un taux de rebond plus faible et une augmentation de 0,7% des revenus par session.
100ms
Amélioration du temps de chargement des pages
0,7 %
Augmentation des revenus par session
L'adhésion de l'entreprise ne se traduit pas toujours par des performances
Malgré une forte adhésion aux performances au sein de l'entreprise, si les performances ne sont pas définies comme critères de livraison des produits, elles peuvent facilement disparaître. Lorsque nous avons repensé le site Web de Zalando en 2020, nous nous sommes concentrés sur la fourniture de nouvelles fonctionnalités tout en préservant une excellente expérience utilisateur, et en appliquant un nouveau look au site Web avec des polices personnalisées et des couleurs plus vives. Toutefois, lorsque le site Web et l'application repensés étaient prêts à être publiés, les métriques des utilisateurs de la première heure ont révélé que la nouvelle version était plus lente. First Contentful Paint a été jusqu'à 53% plus lent, et notre temps d'interaction mesuré a été jusqu'à 59% plus lent.
Le Web chez Zalando
Le site Web Zalando est créé par une équipe de base qui développe un framework, avec plus de 15 équipes de fonctionnalités contribuant aux microservices d'interface. Tout en prenant en charge la nouvelle version, nous avons également transféré une partie de notre site Web vers une architecture plus centralisée.
L'architecture précédente appelée Mosaic permettait de mesurer les performances des pages à l'aide de métriques internes. Toutefois, il était difficile de comparer les métriques de performances avant leur déploiement auprès d'utilisateurs réels, car nous manquions d'outils internes de surveillance des performances en laboratoire. Malgré un déploiement quotidien, une boucle de rétroaction d'environ une journée a été observée chez les développeurs chargés d'améliorer les performances.
Les signaux Web et Lighthouse à la rescousse
Nous n'étions pas entièrement satisfaits de nos métriques internes, car elles ne se sont pas adaptées à notre nouvelle configuration. Plus important encore, elle n'était pas axée sur l'expérience client. Nous sommes passés aux Core Web Vitals, qui proposaient un ensemble de métriques condensé, complet et axé sur l'utilisateur.
Afin d'améliorer les performances avant le lancement, nous devions créer un environnement d'atelier approprié. Nous avons ainsi obtenu des mesures reproductibles, en plus des conditions de test représentant notre 90e centile de données réelles. Désormais, les ingénieurs qui s'efforçaient d'améliorer les performances savaient sur quoi concentrer leurs efforts pour obtenir le plus d'impact possible. Nous utilisions déjà les rapports d'audit Lighthouse en local. Notre première itération consistait donc à développer un service basé sur le module de nœud Lighthouse, où les modifications pouvaient être testées à partir de notre environnement de préproduction. Cela nous a fourni une boucle de rétroaction fiable sur les performances d'environ une heure, ce qui nous a permis de fournir des performances équivalentes et d'enregistrer notre version.
Transmettre aux développeurs des informations sur les performances des demandes d'extraction
Nous ne voulions pas nous arrêter là, car nous voulions en profiter non seulement pour être réactifs vis-à-vis des performances, mais aussi proactifs. Passer du module de nœud Lighthouse au serveur LHCI (Lighthouse CI) n'a pas été trop difficile. Nous avons opté pour la solution auto-hébergée afin d'offrir une meilleure intégration avec les services existants de notre entreprise. Notre application serveur LHCI est créée sous la forme d'une image Docker, qui est ensuite déployée sur notre cluster Kubernetes avec une base de données PostgreSQL, puis transmise à notre GitHub.
Notre framework fournissait déjà aux développeurs des informations sur les performances : la taille des lots de composants était comparée aux valeurs de seuil à chaque commit. Nous pouvons désormais générer des rapports sur les métriques Lighthouse en tant que vérifications d'état GitHub. Ceux-ci entraînent l'échec du pipeline CI s'ils n'atteignent pas les seuils de performances, avec un lien vers les rapports Lighthouse détaillés, comme illustré dans les images suivantes.
Étendre la couverture des performances
Nous avons commencé par une approche très pragmatique. Actuellement, Lighthouse ne s'exécute que sur deux de nos pages les plus importantes : la page d'accueil et la page d'informations détaillées sur le produit. Heureusement, la CI Lighthouse permet d'étendre facilement les configurations d'exécution. Les équipes chargées des fonctionnalités qui travaillent sur des pages spécifiques de notre site Web peuvent configurer leurs assertions et leurs formats d'URL correspondants. Nous sommes convaincus que la couverture de nos performances va augmenter.
Nous sommes désormais beaucoup plus confiants lors de la création de versions plus importantes, et les développeurs peuvent bénéficier d'une boucle de rétroaction beaucoup plus courte sur les performances de leur code.