Optymalizacja wydajności to nie jednorazowy projekt. Wydajność to praktyka ciągła.
Proces oznacza: zespół co tydzień przegląda dane o wydajności. Zespół omawia wydajność na krótkich spotkaniach. Zespół myśli o wydajności, pisząc kod. Zespół świętuje poprawy wydajności.
Bez procesu: wydajność z czasem spada. Zespół nie myśli o wydajności, dopóki strona się nie zepsuje.
Z procesem: wydajność z czasem rośnie. Zespół buduje kulturę wydajności. Wydajność ma wartość.
Cotygodniowy rytuał wydajności
Co poniedziałek rano: zespół przegląda raport wydajności.
Raport pokazuje: co się poprawiło w zeszłym tygodniu, co się pogorszyło, co wymaga uwagi w tym tygodniu.
Dyskusja zespołu: dlaczego LCP strony kasy się pogorszył? Czy to wina nowego kodu? Czy trzeba to zbadać?
Efekt: ustalone zadania do wykonania. Poprawy wydajności trafiają do sprintu.
Prawdziwy przykład cotygodniowego rytuału:
- Poniedziałek, godz. 10: spotkanie przeglądu wydajności
- Przegląd wskaźników: LCP strony głównej poprawił się o 0,2 sekundy (dobrze), INP strony produktu pogorszył się o 50 milisekund (do zbadania)
- Analiza przyczyn: na stronie produktu uruchomiono nową funkcję (silnik rekomendacji). Funkcja dodała JavaScript, który zwiększył INP.
- Zadania: odłożyć ładowanie JavaScriptu silnika rekomendacji, zoptymalizować kod funkcji
- Odpowiedzialny: inżynier przypisany do naprawy
- Termin: wdrożenie w środę
Włączanie wydajności w proces tworzenia
Przed wdrożeniem funkcji: inżynier mierzy jej wpływ na wydajność.
Funkcja dodaje możliwości. Funkcja dodaje też kod. Kod zwiększa rozmiar pakietu. Większy pakiet może pogorszyć wydajność.
Rozwiązanie: budżet wydajności. Funkcja nie może go przekroczyć.
Przykład: nowa funkcja strony kasy. Budżet: dodać nie więcej niż 20 kilobajtów do pakietu JavaScriptu. Inżynier wdraża funkcję. Funkcja dodaje 25 kilobajtów. Funkcja przekracza budżet. Inżynier musi zoptymalizować: usunąć nieużywany kod, podzielić pakiet, odłożyć ładowanie kodu. Inżynier zmniejsza funkcję do 20 kilobajtów. Funkcja zostaje zatwierdzona.
Prawdziwy przykład: wdrożenie silnika rekomendacji produktów
Funkcja: pokazywanie spersonalizowanych rekomendacji produktów na stronie produktu.
Budżet wydajności: dodać nie więcej niż 50 kilobajtów do pakietu.
Pierwsze wdrożenie: 50 kilobajtów. Dokładnie w budżecie.
Testy: zmierz LCP i INP.
- LCP rośnie z 2 do 2,3 sekundy (niedopuszczalne, przekracza budżet)
- INP rośnie ze 150 do 300 milisekund (niedopuszczalne, przekracza budżet)
Optymalizacja inżyniera: leniwe ładowanie rekomendacji poniżej pierwszego ekranu, odłożenie wczytywania danych rekomendacji do chwili, gdy strona będzie interaktywna.
Nowe wdrożenie: te same 50 kilobajtów, ale:
- LCP wraca do 2 sekund (w budżecie)
- INP wraca do 170 milisekund (w budżecie)
Funkcja zatwierdzona: wymagania wydajności spełnione.
Raportowanie dla zarządu
Miesięczny raport dla zarządu: trendy wydajności i wpływ na biznes.
Struktura raportu:
- Cele wydajności i postęp
- Porównanie z konkurencją (jak wypadamy na tle innych)
- Wpływ na biznes (przychody z poprawy wydajności)
- Najbliższy cel (co optymalizujemy dalej)
Prawdziwy przykład miesięcznego raportu dla zarządu:
- Cel: 90 procent użytkowników z LCP poniżej 2,5 sekundy
- Postęp: obecnie 87 procent (wzrost z 85 procent w zeszłym miesiącu)
- Termin: na dobrej drodze, by osiągnąć cel za dwa miesiące
- Pozycja na tle konkurencji: mediana LCP konkurentów to 2 sekundy, nasz LCP to 2 sekundy (na poziomie mediany, konkurencyjnie)
- Wpływ na biznes: poprawy wydajności z zeszłego miesiąca zwiększyły ukończenie zakupów w kasie o 0,5 procent. Przy 100 tysiącach odwiedzających miesięcznie to 500 dodatkowych konwersji. Przy wartości zamówienia 100 dolarów to 50 tysięcy dolarów dodatkowych przychodów miesięcznie. 600 tysięcy dolarów rocznie.
- Najbliższy cel: optymalizacja wersji mobilnej (LCP na telefonach jest o 1 sekundę wolniejszy niż na komputerach, to szansa na poprawę konwersji mobilnej)
Zatrudnianie z myślą o kulturze wydajności
Zatrudniaj inżynierów, którym zależy na wydajności. Pytanie rekrutacyjne: opowiedz o optymalizacji wydajności, którą wdrożono.
Zatrudniaj product managerów, którzy cenią wydajność. Wydajność poprawia doświadczenie użytkownika i konwersję. Product managerowie powinni znać wpływ na biznes.
Buduj kulturę zespołu, w której wydajność ma wartość. Świętuj sukcesy wydajności. Doceniaj inżynierów, którzy poprawili LCP o 0,5 sekundy.
Prawdziwy przykład: zatrudnianie z myślą o kulturze wydajności.
Pytanie do kandydata na inżyniera: opisz sytuację, w której zoptymalizowano kod pod kątem wydajności. Jaki był problem? Jak zmierzono poprawę? Jaki był wpływ na biznes?
Dobra odpowiedź: mieliśmy wolny punkt końcowy API, który odpowiadał 2 sekundy. Użytkownicy narzekali na wolną rejestrację. Zrobiono profilowanie kodu i znaleziono kosztowne zapytanie do bazy. Dodano buforowanie. Czas odpowiedzi poprawił się do 200 milisekund. Ukończenie rejestracji wzrosło o 2 procent. 50 dodatkowych klientów miesięcznie. 250 tysięcy dolarów dodatkowych przychodów rocznie.
Odpowiedź pokazuje: zrozumienie techniczne (profilowanie, buforowanie), pomiar (przed i po), myślenie biznesowe (wpływ na rejestracje i przychody).
Zatrudnij tę osobę. Myśli o wydajności i o biznesie.
Najczęstsze pytania
Jak zmotywować zespół, by traktował wydajność priorytetowo?
Powiąż wydajność ze wskaźnikami biznesu. Pokaż, że poprawa wydajności o 1 procent oznacza wzrost konwersji o 1 procent. Policz wpływ na przychody. Pokaż koszt optymalizacji w porównaniu z zyskiem. Inżynierom zależy na wpływie. Wydajność ma wpływ mierzalny. Inżynierowie ją uwzględnią. Dzięki kreatorowi stron WEMASY możesz to ustawić bezpośrednio na swojej stronie.
Czy optymalizacja wydajności ma być osobnym zespołem, czy częścią wszystkich zespołów?
Częścią wszystkich zespołów. Każdy inżynier powinien myśleć o wydajności. Osobny zespół wydajności staje się wąskim gardłem. Lepsza jest rozproszona odpowiedzialność. Każdy inżynier odpowiada za wydajność swojego kodu. Kierownik zespołu rozlicza zespół.
Jak pogodzić nowe funkcje z optymalizacją wydajności?
Wydajność to też funkcja. Nowa funkcja plus jej wpływ na wydajność to łączny koszt. Zaplanuj budżet na jedno i drugie. Przykład: nowa funkcja kosztuje jeden sprint. Optymalizacja jej wydajności kosztuje jeszcze 0,5 sprintu. Łączny koszt to 1,5 sprintu. Zarezerwuj czas na oba. Funkcję i wydajność wdrażaj razem.
Co zrobić, gdy zarządowi nie zależy na wydajności?
Pokaż wpływ na biznes. Poprawa konwersji o 1 procent to 50 tysięcy dolarów miesięcznie (dla typowego sklepu internetowego). Zarząd rozumie przychody. Poprawa wydajności to wzrost przychodów. Zarząd zacznie się tym interesować.
Jak długo buduje się kulturę wydajności?
Od trzech do sześciu miesięcy. Pierwszy miesiąc: ustal wskaźniki i panel. Drugi miesiąc: ruszają cotygodniowe przeglądy, rośnie świadomość zespołu. Trzeci miesiąc: zespół zaczyna uwzględniać wydajność w kodzie. Po sześciu miesiącach: wydajność jest częścią DNA zespołu. Nowi inżynierowie uczą się kultury wydajności od pierwszego dnia.
Jak utrzymać kulturę wydajności, gdy firma rośnie?
Udokumentuj praktyki. Wprowadzaj nowych inżynierów w kulturę wydajności. Pierwszy dzień: pokaż panel wydajności. Pierwszy tydzień: przydziel zadanie poprawy wydajności. Pierwszy miesiąc: ustal cel wydajności. Nowi inżynierowie uczą się kultury. Kultura się utrzymuje.