Lowe’s Website gehört zu den E-Commerce-Websites mit der schnellsten Leistung

Das Site Speed Team von Lowe’s hat ein automatisiertes System für Leistungstests und ‑monitoring entwickelt, mit dem Pull-Anfragen anhand von Leistungsbudgets getestet werden. So werden Leistungsverschlechterungen in der Produktion verhindert.

Abhimanyu Raibahadur

Ashish Choudhury

Dhilip venkatesh Uvarajan

Dinakar Chandolu

Garima Mimani

Safwan Samla

Lowe's ist ein Einzelhändler für Heimwerkerbedarf mit einem Umsatz von fast 90 Milliarden US-Dollar, der rund 2.200 Filialen betreibt und mehr als 300.000 Mitarbeiter beschäftigt. Durch die Entwicklung eines automatisierten Test- und Überwachungssystems, das verhindert, dass Leistungsregressionen in der Produktion bereitgestellt werden, konnte das Site Speed Team von Lowe’s die Leistung der Website verbessern und gehört nun zu den besten Einzelhandelswebsites.

Problem

Das Ziel des Site Speed-Teams ist es, die Website von Lowe's in Bezug auf die Seitenladeleistung zu einer der schnellsten E-Commerce-Websites zu machen. Bevor sie ihr automatisiertes Test- und Überwachungssystem entwickelten, konnten die Websiteentwickler von Lowe’s die Leistung in Vorproduktionsumgebungen nicht automatisch messen. Mit vorhandenen Tools wurden Tests nur in der Produktionsumgebung durchgeführt. Infolgedessen gelangten minderwertige Builds in die Produktion, was zu einer schlechten Nutzererfahrung führte. Diese minderwertigen Builds blieben in der Produktion, bis sie vom Site Speed Team erkannt und vom Autor zurückgesetzt wurden.

Lösung

Das Site Speed-Team hat Open-Source-Tools verwendet, um ein automatisiertes System zum Testen und Überwachen der Leistung für Vorproduktionsumgebungen zu entwickeln. Das System misst die Leistung jeder Pull-Anfrage (Pull Request, PR) und verhindert, dass die PR in die Produktion überführt wird, wenn sie das Leistungsbudget und die Messwertkriterien des Site Speed-Teams nicht erfüllt. Das System misst auch die SEO- und ADA-Konformität.

Auswirkungen

Bei einer Stichprobe von einem Team über 16 Wochen, in denen 102 Builds bereitgestellt wurden, verhinderte das automatisierte System für Leistungstests und ‑monitoring, dass 32 Builds mit unzureichender Leistung in die Produktion gingen.

Früher hat es drei bis fünf Tage gedauert, bis das Site Speed-Team Entwickler darüber informiert hat, dass sie Leistungsregressionen in der Produktion eingeführt haben. Jetzt werden Entwickler fünf Minuten nach dem Einreichen einer Pull-Anfrage in einer Vorproduktionsumgebung automatisch über Leistungsprobleme informiert.

Die Codequalität verbessert sich im Laufe der Zeit, was daran zu erkennen ist, dass weniger Pull-Requests wegen Leistungseinbußen gekennzeichnet werden. Das Site Speed Team schränkt außerdem die Governance-Budgets schrittweise ein, um die Websitequalität kontinuierlich zu verbessern.

Insgesamt hat die klare Zuweisung von problematischem Code die Engineering-Kultur verändert. Anstatt reaktive Korrekturen zu scheuen, weil nie klar war, wer die Probleme tatsächlich verursacht hat, kann das Team proaktive Optimierungen vornehmen, da die Verantwortung für problematischen Code objektiv zugeordnet werden kann.

Implementierung

Das Herzstück der Site Speed Governance (SSG) App ist Lighthouse CI. Die SSG-App verwendet Lighthouse, um die Seitenleistung jedes Pull-Requests zu validieren und zu prüfen.

Die SSG-App führt dazu, dass ein Build fehlschlägt, wenn das vom Site Speed Team definierte Leistungsbudget und die Messwertziele nicht erreicht werden. Es wird nicht nur die Ladeleistung, sondern auch SEO, PWA und Barrierefreiheit erzwungen. Der Status kann sofort an Autoren, Prüfer und SRE-Teams gemeldet werden. Sie kann auch so konfiguriert werden, dass die Prüfungen umgangen werden, wenn Ausnahmen erforderlich sind.

Automatisierter Prozess zur Geschwindigkeitskontrolle (Automated Speed Governance, ASG)

Spinnaker

Startpunkt. Ein Entwickler führt seinen Code mit einer Vorproduktionsumgebung zusammen.

1. Stellen Sie die Vorproduktionsumgebung mit CDN-Assets bereit.
2. Prüfen Sie, ob das Deployment erfolgreich war.
3. Führen Sie einen Docker-Container aus, um mit dem Erstellen der ASG-Anwendung zu beginnen oder eine Benachrichtigung zu senden (im Falle eines Bereitstellungsfehlers).

Jenkins und Lighthouse

1. Erstellen Sie die ASG-Anwendung mit Jenkins.
2. Führen Sie einen benutzerdefinierten Docker-Container aus, auf dem Chrome und Lighthouse installiert sind. Rufen Sie lighthouserc.json aus der SSG-App ab und führen Sie lhci autorun --collect-url=https://example.com aus.

Jenkins und SSG-App

1. Extrahieren Sie assertion-results.json aus lhci und vergleichen Sie sie mit vordefinierten Budgets in budgets.json. Speichern Sie die Ausgabe als Textdatei und laden Sie sie zur späteren Verwendung in Nexus hoch.
2. Vergleichen Sie die aktuelle assertion-results.json mit dem letzten erfolgreichen Build (aus Nexus heruntergeladen) und speichern Sie sie als Textdatei.
3. Erstellen Sie eine HTML-E-Mail mit den Informationen zum Erfolg oder Misserfolg.
4. Senden Sie die E-Mail mit Jenkins an die entsprechenden Verteilerlisten.