Das Webteam von Zalando stellte fest, dass die Einbindung von Lighthouse CI einen proaktiven Ansatz für die Leistung ermöglichte. Automatisierte Statusprüfungen konnten den aktuellen Commit mit dem Hauptzweig vergleichen, um Leistungseinbußen zu verhindern.
Mit mehr als 35 Millionen aktiven Kunden ist Zalando Europas führende Online-Modeplattform. In diesem Beitrag erläutern wir, warum wir mit Lighthouse CI begonnen haben, wie einfach die Implementierung ist und welche Vorteile unser Team hat.
Wir bei Zalando kennen den Zusammenhang zwischen Websiteleistung und Umsatz. In der Vergangenheit haben wir getestet, wie sich eine künstliche Erhöhung der Ladezeit auf Katalogseiten auf die Absprungraten, Conversion-Raten und den Umsatz pro Nutzer auswirkt. Die Ergebnisse waren eindeutig. Eine Verbesserung der Seitenladezeit um 100 Millisekunden führte zu mehr Interaktionen, einer niedrigeren Absprungrate und einer Steigerung des Umsatzes pro Sitzung um 0,7 %.
100ms
Verbesserung der Seitenladezeit
0,7 %
Höherer Umsatz pro Sitzung
Die Zustimmung des Unternehmens entspricht nicht immer der Leistung.
Trotz der starken Zustimmung für die Leistung innerhalb des Unternehmens kann die Leistung leicht verloren gehen, wenn die Leistung nicht als Produktlieferkriterium festgelegt ist. Bei der Neugestaltung der Zalando-Website im Jahr 2020 haben wir uns auf die Bereitstellung neuer Funktionen konzentriert und dabei gleichzeitig eine hervorragende Nutzererfahrung beibehalten. Außerdem wurde die Website mit benutzerdefinierten Schriftarten und lebendigeren Farben überarbeitet. Als jedoch die neu gestaltete Website und App zur Veröffentlichung bereit waren, zeigten die Messwerte der ersten Nutzer, dass die neue Version langsamer war. First Contentful Paint war bis zu 53% langsamer und die gemessene Zeit bis Interaktivität um bis zu 59 %.
Das Web bei Zalando
Die Zalando-Website wird von einem Kernteam erstellt, das ein Framework entwickelt, bei dem über 15 Feature-Teams Frontend-Mikrodienste beitragen. Neben der Unterstützung der neuen Version haben wir auch einen Teil unserer Website in eine zentralisierte Architektur umgewandelt.
In der vorherigen Architektur namens Mosaic war es möglich, die Seitenleistung mit internen Messwerten zu messen. Es war jedoch schwierig, die Leistungsmesswerte vor der Einführung für echte Nutzer zu vergleichen, da es keine internen Tools zur Leistungsüberwachung des Labors gab. Trotz der täglichen Bereitstellung gab es für Entwickler, die an Leistungsverbesserungen arbeiteten, eine Feedbackschleife von etwa einem Tag.
Web Vitals und Lighthouse sind die Rettung
Wir waren nicht ganz zufrieden mit unseren internen Messwerten, da sie sich nicht gut an unser neues Umfeld anpassten. Und was noch wichtiger war: Die Kundenerfahrung stand nicht im Mittelpunkt. Wir sind auf die Core Web Vitals umgestiegen, da diese eine kompakte, aber umfassende und nutzerorientierte Gruppe von Messwerten bieten.
Um die Leistung vor der Veröffentlichung zu verbessern, mussten wir eine geeignete Lab-Umgebung erstellen. Zusätzlich zu den Testbedingungen, die unser 90. Perzentil der Felddaten darstellten, lieferten sie reproduzierbare Messungen. Die Entwickler, die an Leistungsverbesserungen arbeiteten, wussten jetzt, worauf sie sich konzentrieren sollten, um die größte Wirkung zu erzielen. Wir nutzten bereits Lighthouse-Prüfberichte lokal. Daher haben wir zuerst einen Dienst entwickelt, der auf dem Lighthouse-Knotenmodul basiert. Hier konnten Änderungen in unserer Staging-Umgebung getestet werden. So konnten wir eine zuverlässige Feedbackschleife von etwa einer Stunde zur Leistungssteigerung bereitstellen und die Leistung entsprechend anpassen und unser Release speichern.
Entwicklern Feedback zur Leistung bei Pull-Anfragen geben
Damit wollten wir nicht nur auf die Leistung reagieren, sondern auch proaktiv. Der Wechsel vom Lighthouse-Knotenmodul zum LHCI-Server (Lighthouse CI) war nicht allzu schwierig. Wir haben uns für die selbst gehostete Lösung entschieden, um eine bessere Integration in unsere bestehenden Unternehmensdienste zu ermöglichen. Unsere LHCI-Serveranwendung wird als Docker-Image erstellt, das dann zusammen mit einer PostgreSQL-Datenbank in unserem Kubernetes-Cluster bereitgestellt und an unser GitHub-Repository gesendet wird.
Unser Framework gab Entwicklern bereits Feedback zur Leistung – die Größe von Komponenten-Bundles wurde bei jedem Commit mit Schwellenwerten verglichen. Jetzt können Lighthouse-Messwerte als GitHub-Statusprüfungen gemeldet werden. Diese führen dazu, dass die CI-Pipeline fehlschlägt, wenn die Leistungsgrenzwerte nicht erreicht werden. Dabei wird ein Link zu den detaillierten Lighthouse-Berichten angezeigt, wie in den folgenden Bildern dargestellt.
Erweiterte Leistungsabdeckung
Wir begannen mit einem sehr pragmatischen Ansatz. Derzeit läuft Lighthouse nur auf zwei unserer wichtigsten Seiten: der Startseite und der Seite mit den Produktdetails. Glücklicherweise lässt sich mit Lighthouse CI die Ausführungskonfigurationen ganz einfach erweitern. Feature-Teams, die an bestimmten Seiten unserer Website arbeiten, können entsprechende URL-Muster und Assertions einrichten. Wir sind ziemlich zuversichtlich, dass sich unsere Leistungsabdeckung erhöhen wird.
Wir sind jetzt viel sicherer, wenn wir größere Releases erstellen, und Entwickler können eine viel kürzere Feedbackschleife zur Leistung ihres Codes nutzen.