L'équipe Web de Zalando a constaté que l'intégration de la CI Lighthouse a permis d'adopter une approche proactive des performances, avec des vérifications d'état automatisées permettant de comparer le commit actuel à la branche principale afin d'é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 l'intégration continue Lighthouse, la facilité d'implémentation et les avantages pour notre équipe.
Chez Zalando, nous connaissons la relation entre les performances du site Web et les revenus. Par le passé, nous avons testé l'impact de l'augmentation artificielle du temps de chargement sur les pages de catalogue sur les taux de rebond, les taux de conversion et les revenus par utilisateur. Les résultats étaient clairs. Une amélioration de 100 millisecondes du temps de chargement de la page a permis d'augmenter l'engagement, de réduire le taux de rebond et d'augmenter les revenus par session de 0,7 %.
100 ms
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é l'adhésion forte 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 passer à la trappe. Lorsque nous avons repensé le site Web de Zalando en 2020, nous nous sommes concentrés sur l'ajout de nouvelles fonctionnalités tout en conservant une excellente expérience utilisateur et en modernisant le 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 premiers utilisateurs ont révélé que la nouvelle version était plus lente. First Contentful Paint était jusqu'à 53% plus lent, et notre mesure du temps de réponse était jusqu'à 59% plus lente.
Le Web chez Zalando
Le site Web de Zalando est créé par une équipe de base qui développe un framework, avec plus de 15 équipes de fonctionnalités qui contribuent aux microservices de front-end. Tout en prenant en charge la nouvelle version, nous avons également migré 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 le déploiement auprès d'utilisateurs réels, car nous manquions d'outils de surveillance des performances internes. Malgré le déploiement quotidien, une boucle de rétroaction d'environ une journée était nécessaire pour les développeurs qui travaillaient sur l'amélioration des performances.
Web Vitals et Lighthouse à la rescousse
Nous n'étions pas entièrement satisfaits de nos métriques internes, car elles ne s'adaptaient pas bien à notre nouvelle configuration. Plus important encore, elles ne sont pas centrées sur l'expérience client. Nous sommes passés aux Core Web Vitals, car ils fournissent un ensemble de métriques condensé, mais complet et axé sur l'utilisateur.
Pour améliorer les performances avant la publication, nous avons dû créer un environnement de test approprié. Cela a permis d'obtenir des mesures reproductibles, en plus des conditions de test représentant le 90e centile de nos données sur le terrain. Les ingénieurs travaillant sur l'amélioration des performances savaient désormais où concentrer leurs efforts pour obtenir le plus d'impact. Nous utilisions déjà les rapports d'audit Lighthouse localement. Notre première itération a donc consisté à 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 donné une boucle de rétroaction fiable sur les performances d'environ une heure, ce qui nous a permis d'égaliser les performances et de sauver notre version !
Envoyer des commentaires sur les performances aux développeurs concernant les demandes d'extraction
Nous ne voulions pas nous arrêter là, car nous voulions profiter de cette opportunité pour être non seulement réactifs aux performances, mais aussi proactifs. Le passage du module de nœud Lighthouse au serveur Lighthouse CI (LHCI) n'a pas été trop difficile. Nous avons opté pour la solution auto-hébergée afin de mieux intégrer nos services existants. Notre application de serveur LHCI est créée en tant qu'image Docker, qui est ensuite déployée dans notre cluster Kubernetes avec une base de données PostgreSQL et envoyée à notre GitHub.
Notre framework fournissait déjà des commentaires sur les performances aux développeurs : les tailles de bundle de composants étaient comparées 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. Si ces éléments ne respectent pas les seuils de performances, le pipeline de CI échoue, 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 n'est exécuté que sur deux de nos pages les plus importantes : la page d'accueil et la page d'informations détaillées sur les produits. Heureusement, Lighthouse CI permet d'étendre facilement les configurations d'exécution. Les équipes chargées des fonctionnalités travaillant sur des pages spécifiques de notre site Web peuvent configurer leur format d'URL et leurs assertions de correspondance. Nous sommes convaincus que cette approche nous permettra d'améliorer la couverture de nos performances.
Nous sommes désormais beaucoup plus confiants lorsque nous créons des 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.