Jak firma Zalando zmniejszyła czas przekazywania opinii o wydajności z 1 dnia do 15 minut dzięki Lighthouse CI

Zespół internetowy z Zalando odkrył, że integracja narzędzia Lighthouse CI umożliwiła proaktywne podejście do wydajności – automatyczne kontrole stanu umożliwiają porównanie bieżącego zobowiązania do głównej gałęzi, co pozwoli zapobiec spadkom wydajności.

Jan Brockmeyer
Jan Brockmeyer
Jeremy Colin
Jeremy Colin

Z ponad 35 milionami aktywnych klientów Zalando to czołowa internetowa platforma odzieżowa w Europie. W tym poście wyjaśnimy, dlaczego zaczęliśmy korzystać z Lighthouse CI, łatwość wdrożenia i korzyści dla naszego zespołu.

W Zalando znamy związek między skutecznością strony a przychodami. W przeszłości testowaliśmy, jak sztuczne wydłużanie czasu wczytywania stron katalogowych wpływa na współczynniki odrzuceń, współczynniki konwersji i przychody na użytkownika. Wyniki były jasne. Skrócenie czasu wczytywania strony o 100 milisekund przełożyło się na większe zaangażowanie, niższy współczynnik odrzuceń i wzrost przychodów na sesję o 0,7%.

100ms

Skrócenie czasu wczytywania strony

0,7%

Wzrost przychodów na sesję

Zaangażowanie firmy nie zawsze przekłada się na skuteczność

Pomimo dużej skuteczności w firmie, jeżeli skuteczność nie jest określona jako kryterium dostawy produktu, możemy ją łatwo utracić. Podczas projektowania witryny Zalando w 2020 r. skupiliśmy się na wprowadzaniu nowych funkcji, dbając jednocześnie o komfort użytkowników i poprawę jej wyglądu za pomocą niestandardowych czcionek i żywych kolorów. Gdy jednak nowa witryna i aplikacja były gotowe do opublikowania, dane na wczesnym etapie wykazały, że nowa wersja działa wolniej. Pierwsze wyrenderowanie treści było o 53% wolniejsze, a zmierzony czas do pełnej interaktywności był wolniejszy nawet o 59%.

Internet w Zalando

Witryna Zalando jest tworzona przez główny zespół pracujący nad platformą, z mikroserwisów frontendowych korzysta ponad 15 zespołów zajmujących się funkcjami. Podczas obsługi nowej wersji przenieśliśmy też część naszej witryny na bardziej scentralizowaną architekturę.

W poprzedniej architekturze mozaika można było mierzyć wydajność strony za pomocą wewnętrznych danych. Trudno było jednak porównać wskaźniki wydajności przed wdrożeniem ich do programu dla rzeczywistych użytkowników, ponieważ brakowało nam wewnętrznych narzędzi do monitorowania wydajności laboratoryjnych. Pomimo codziennego wdrożenia programiści, którzy pracowali nad poprawą wydajności, poświęcili na to około jednego dnia.

Narzędzia internetowe i latarnia morska na ratunek

Nasze wewnętrzne dane nie spełniły naszych oczekiwań, ponieważ nie przystosowały się do nowej konfiguracji. Co ważniejsze, nie były one koncentrowane na wrażeniach klientów. Przeszliśmy na podstawowe wskaźniki internetowe, ponieważ zapewniają one kompleksowy, a jednocześnie kompleksowy i ukierunkowany na użytkownika zestaw danych.

Aby poprawić wydajność przed udostępnieniem, musieliśmy utworzyć odpowiednie środowisko modułu. Dzięki temu udało nam się uzyskać powtarzalne pomiary oraz warunki testowe reprezentujące 90 centyl danych terenowych. Inżynierowie zajmujący się poprawą wydajności wiedzieli, na czym należy skupić swoje wysiłki, aby uzyskać najlepsze efekty. Użyliśmy już lokalnie raportów kontrolnych z Lighthouse. Dlatego pierwszą iteracją było opracowanie usługi opartej na module węzłów Lighthouse, w której można przetestować zmiany w naszym środowisku przejściowym. Dzięki temu zyskaliśmy pętlę informacji zwrotnych o wydajności, który trwał około godziny, co pozwoliło nam zrównoważyć wydajność i zapisać wersję.

przekazywanie deweloperom opinii o wydajności dotyczących żądań pull,

Nie chcieliśmy na tym poprzestawać, ponieważ chcieliśmy skorzystać nie tylko z reagowania na skuteczność, ale także proaktywnie. Przejście z modułu węzłów Lighthouse na serwer Lighthouse CI (LHCI) nie było zbyt trudne. Zdecydowaliśmy się na rozwiązanie hostowane samodzielnie, aby zapewnić lepszą integrację z naszymi obecnymi usługami firmowymi. Aplikacja serwera LHCI jest tworzona jako obraz Dockera, który jest następnie wdrażany w naszym klastrze Kubernetes razem z bazą danych PostgreSQL i raportuje na GitHubie.

Nasza platforma przekazała już deweloperom opinie na temat wydajności – w każdym zatwierdzeniu rozmiar pakietów komponentów był porównywany z wartościami progowymi. Teraz możemy raportować wskaźniki Lighthouse w postaci kontrol stanu GitHuba. Powoduje to błąd potoku CI, jeśli nie osiąga progów wydajności. Zawierają one link do szczegółowych raportów Lighthouse, które pokazano na poniższych ilustracjach.

Obraz interfejsu GitHuba przedstawiający wiersze udanych kontroli.
Sprawdzanie stanu Lighthouse CI na GitHubie ułatwia programistom analizowanie regresji i rozwiązywanie problemów przed wdrożeniem ich w środowisku produkcyjnym.
Obraz porównawczy w Lighthouse CI przedstawiający porównanie zatwierdzenia z gałęzią główną
Szczegółowy raport o zatwierdzeniach CI Lighthouse w porównaniu z gałęzią główną.

Rozszerzanie zasięgu wśród wyników

Zaczęliśmy od bardzo pragmatycznego podejścia. Obecnie Lighthouse działa tylko na 2 najważniejszych dla nas stronach: stronie głównej i stronie ze szczegółami produktu. Na szczęście narzędzie Lighthouse CI ułatwia rozszerzenie konfiguracji uruchamiania. Zespoły ds. funkcji pracujące na określonych stronach w naszej witrynie mogą skonfigurować pasujące wzorce adresów URL i potwierdzenia. Jesteśmy przekonani, że po wprowadzeniu tych zmian nasza skuteczność wzrośnie.

Teraz mamy znacznie większą pewność przy tworzeniu większych wersji, a deweloperzy mogą korzystać ze znacznie krótszej pętli informacji zwrotnych dotyczących wydajności kodu.