En créant un système automatisé de test et de surveillance des performances, l'équipe Site Speed de Lowe's teste les demandes d'extraction par rapport aux budgets de performance et empêche les régressions de performances avant leur mise en production.
Lowe's est un détaillant de bricolage qui s'élève à près de 90 milliards de dollars. Il gère environ 2 200 magasins et emploie plus de 300 000 collaborateurs. En créant un système de test et de surveillance automatisé qui empêche le déploiement en production de régressions de performances, l'équipe Site Speed Stand a pu améliorer les performances de son site Web et le classer parmi les meilleurs sites de vente au détail.
Problème
L'objectif de l'équipe Site Speed est de faire du site de Lowe's l'un des sites de commerce électronique les plus rapides en termes de temps de chargement des pages. Avant de créer leur système de test et de surveillance automatisé, les développeurs de sites Web de Lowe's ne pouvaient pas mesurer automatiquement les performances dans les environnements de préproduction. Les outils existants n'effectuaient des tests que dans l'environnement de production. Par conséquent, les versions de qualité inférieure ont glissé en production, ce qui générait une expérience utilisateur médiocre. Ces constructions de qualité inférieure resteront en production jusqu'à ce que l'équipe chargée de la vitesse du site les détecte et les annule par l'auteur.
Solution
L'équipe Site Speed a utilisé des outils Open Source pour créer un système automatisé de contrôle et de test des performances pour les environnements de préproduction. Le système mesure les performances de chaque demande d'extraction et encadre celui-ci de l'expédition à la production s'il ne respecte pas le budget de performance et les critères de l'équipe chargée de la vitesse du site. Le système mesure également la conformité avec les normes SEO et ADA.
Impact
Sur un échantillon d'une équipe pendant 16 semaines déployant 102 builds, le système automatisé de test et de surveillance des performances a empêché la mise en production de 32 builds présentant des performances médiocres.
Alors qu'il fallait auparavant trois à cinq jours à l'équipe chargée de la vitesse du site pour informer les développeurs qu'ils avaient mis en production les régressions de performances, le système les informe désormais automatiquement des problèmes de performances cinq minutes après avoir soumis une demande d'extraction dans un environnement de préproduction.
La qualité du code s'améliore au fil du temps, mesurée par le nombre réduit de demandes d'extraction signalées pour des régressions de performances. Par ailleurs, l'équipe chargée de la vitesse du site renforce progressivement les budgets de gouvernance afin d'améliorer continuellement la qualité du site.
En général, la propriété claire d'un code problématique a changé la culture de l'ingénierie. Au lieu de renoncer à des corrections réactives, car il n'était jamais facile de savoir qui a introduit les problèmes, l'équipe peut effectuer des optimisations proactives en s'acquittant de la propriété du code problématique de manière objective.
Implémentation
L'outil Lighthouse CI est au cœur de l'application de gouvernance de la vitesse du site (SSG). L'application SSG utilise Lighthouse pour valider et auditer les performances des pages pour chaque demande d'extraction.
L'application SSG entraîne l'échec d'une compilation si le budget de performances et les objectifs de métriques définis par l'équipe chargée de la vitesse du site ne sont pas atteints. Elle améliore non seulement les performances de chargement, mais aussi le SEO, les PWA et l'accessibilité. Elle peut signaler immédiatement l'état aux auteurs, aux examinateurs et aux équipes d'ingénierie SRE. Il peut également être configuré pour contourner les vérifications lorsque des exceptions sont nécessaires.
Flux du processus de gouvernance de la vitesse automatique (ASG)
Spinnaker
Point de départ. Un développeur fusionne son code dans un environnement de préproduction.
- Déployez l'environnement de préproduction avec des éléments CDN.
- Vérifiez que le déploiement a bien été effectué.
- Exécutez un conteneur Docker pour commencer à créer l'application ASG ou pour envoyer une notification (en cas d'échec du déploiement).
Jenkins et Lighthouse
- Créer l'application ASG avec Jenkins
- Exécutez un conteneur Docker personnalisé sur lequel Chrome et Lighthouse sont installés.
Extrayez
lighthouserc.jsonde l'application SSG et exécutezlhci autorun --collect-url=https://example.com.
Jenkins et application SSG
- Extrayez
assertion-results.jsonde lhci et comparez-le aux budgets prédéfinis dansbudgets.json. Enregistrez les résultats au format texte et importez-les sur Nexus pour les prochaines comparaisons. - Comparez la version
assertion-results.jsonactuelle à la dernière compilation réussie (téléchargée à partir de Nexus), puis enregistrez-la au format texte. - Créez un e-mail HTML contenant des informations sur la réussite ou l'échec.
- Envoyez l'e-mail aux listes de distribution concernées à l'aide de Jenkins.