Das Webteam von Zalando stellte fest, dass die Integration von Lighthouse CI einen proaktiven Ansatz für die Leistung ermöglichte. Mit automatisierten Statusprüfungen konnte der aktuelle Commit mit dem Hauptzweig verglichen werden, um Leistungsrückgänge zu verhindern.
Mit über 35 Millionen aktiven Kunden ist Zalando Europas führende Online-Modeplattform. In diesem Beitrag erklären wir, warum wir Lighthouse CI verwenden, wie einfach die Implementierung ist und welche Vorteile es für unser Team bietet.
Bei Zalando wissen wir, wie wichtig die Websiteleistung für den Umsatz ist. 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 um 100 Millisekunden verkürzte Seitenladezeit führte zu mehr Interaktionen, einer niedrigeren Absprungrate und einem Umsatzanstieg pro Sitzung von 0,7 %.
100 ms
Verbesserung der Seitenladezeit
0,7 %
Umsatz pro Sitzung gesteigert
Die Unterstützung des Unternehmens führt nicht immer zu einer Leistungssteigerung
Trotz des starken Leistungseinkaufs im Unternehmen kann die Leistung leicht verloren gehen, wenn sie nicht als Kriterium für die Produktbereitstellung festgelegt wird. Bei der Neugestaltung der Zalando-Website im Jahr 2020 haben wir uns darauf konzentriert, neue Funktionen zu entwickeln und gleichzeitig die Nutzerfreundlichkeit beizubehalten. Außerdem haben wir die Website mit benutzerdefinierten Schriftarten und leuchtenderen Farben aufgefrischt. Als die neu gestaltete Website und App jedoch zur Veröffentlichung bereit waren, zeigten die Messwerte der frühen Nutzer, dass die neue Version langsamer war. Die First Contentful Paint war um bis zu 53% langsamer und die gemessene Zeit bis zur Interaktivität um bis zu 59 %.
Das Web bei Zalando
Die Zalando-Website wird von einem Kernteam erstellt, das ein Framework entwickelt, mit über 15 Funktionsteams, die Frontend-Mikrodienste beisteuern. Neben der Unterstützung der neuen Version haben wir auch einen Teil unserer Website auf eine zentralisiertere Architektur umgestellt.
Die vorherige Architektur namens Mosaic bot eine Möglichkeit, die Seitenleistung mit internen Messwerten zu messen. Es war jedoch schwierig, Leistungsmesswerte vor der Einführung bei echten Nutzern zu vergleichen, da wir keine internen Tools zur Leistungsüberwachung im Lab hatten. Trotz täglicher Bereitstellung gab es für Entwickler, die an Leistungsverbesserungen arbeiteten, eine Feedbackschleife von etwa einem Tag.
Web Vitals und Lighthouse zur Rettung
Wir waren mit unseren internen Messwerten nicht ganz zufrieden, da sie sich nicht gut an unsere neue Konfiguration anpassen ließen. Noch wichtiger ist, dass sie nicht auf die Kundenerfahrung ausgerichtet waren. Wir sind zu den Core Web Vitals übergegangen, da sie eine kompakte, aber umfassende und nutzerorientierte Reihe von Messwerten bieten.
Um die Leistung vor der Veröffentlichung zu verbessern, mussten wir eine geeignete Lab-Umgebung schaffen. So konnten wir neben Testbedingungen, die dem 90. Perzentil unserer Felddaten entsprechen, auch reproduzierbare Messungen durchführen. Jetzt wussten die Entwickler, die an Leistungsverbesserungen arbeiteten, wo sie ihre Bemühungen am besten konzentrieren sollten, um den größten Effekt zu erzielen. Wir haben bereits lokal Lighthouse-Auditberichte verwendet. Bei unserer ersten Iteration haben wir also einen Dienst auf der Grundlage des Lighthouse-Knotenmoduls entwickelt, in dem Änderungen in unserer Staging-Umgebung getestet werden konnten. So hatten wir eine zuverlässige Feedbackschleife für die Leistung von etwa einer Stunde, mit der wir die Leistung optimieren und die Veröffentlichung retten konnten.
Entwicklern Feedback zur Leistung von Pull-Anfragen geben
Wir wollten aber nicht nur reagieren, sondern auch proaktiv werden. Der Wechsel vom Lighthouse-Knotenmodul zum Lighthouse CI (LHCI)-Server 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 den Entwicklern bereits einige Leistungsinformationen: Die Größe der Komponenten-Bundles wurde bei jedem Commit mit Grenzwerten verglichen. Jetzt können wir Lighthouse-Messwerte als GitHub-Statusprüfungen melden. Wenn diese nicht die Leistungsgrenzwerte erreichen, führt dies zu einem Fehler in der CI-Pipeline. In diesem Fall wird ein Link zu den detaillierten Lighthouse-Berichten angezeigt, wie in den folgenden Bildern zu sehen.
Leistungsabdeckung erweitern
Wir haben mit einem sehr pragmatischen Ansatz begonnen. Derzeit wird Lighthouse nur auf zwei unserer wichtigsten Seiten ausgeführt: der Startseite und der Produktdetailseite. Glücklicherweise können Sie mit Lighthouse CI die Ausführungskonfigurationen ganz einfach erweitern. Feature-Teams, die an bestimmten Seiten unserer Website arbeiten, können ein passendes URL-Muster und entsprechende Behauptungen einrichten. Wir sind zuversichtlich, dass sich dadurch die Abdeckung der Leistungsdaten verbessern wird.
Wir sind jetzt viel selbstbewusster, wenn wir größere Releases erstellen, und Entwickler können viel schneller Feedback zur Leistung ihres Codes erhalten.