Wydajność: diagnozowanie i rozwiązywanie problemów, czyli jak znaleźć i naprawić spowolnienia

Wydajność spada. Strona, która ładowała się 2 sekundy, teraz ładuje się 4 sekundy. Coś się zmieniło.

Diagnoza odpowiada na pytania: co się zmieniło i dlaczego wydajność spadła.

Przyczyny: nowa funkcja dodała duży pakiet JavaScriptu. Zapytanie do bazy danych zrobiło się wolne. Dodano skrypt strony trzeciej. Wzrósł rozmiar obrazów. Serwer się przeciążył.

Systematyczna diagnoza znajduje przyczynę. Systematyczna naprawa ją usuwa.

Schemat diagnozowania

Krok pierwszy: zidentyfikuj objaw. LCP wzrósł z 2 do 4 sekund. CLS wzrósł z 0,05 do 0,2. INP wzrósł ze 100 do 400 milisekund.

Krok drugi: ustal oś czasu. Kiedy zaczęło się pogorszenie? W zeszłym tygodniu? Wczoraj? Godzinę temu? Oś czasu zawęża poszukiwania.

Krok trzeci: powiąż z wprowadzonymi zmianami. Jaki kod się zmienił? Jakie funkcje wdrożono? Co zmieniło się w infrastrukturze? Korelacja wskazuje przyczynę.

Krok czwarty: wyizoluj przyczynę. Wydajność spadła. Hipoteza: nowy pakiet JavaScriptu. Test: zmierz LCP z wyłączonym nowym pakietem. LCP wraca do 2 sekund. Hipoteza potwierdzona.

Krok piąty: napraw albo cofnij zmianę. Napraw przyczynę (zoptymalizuj pakiet) albo cofnij (wycofaj zmianę). Decyzja zależy od powagi problemu.

Prawdziwy przykład: spadek wydajności sklepu internetowego

Objaw: LCP wzrósł z 2 sekund do 3,5 sekundy. Wykryty przez alert z monitoringu.

Oś czasu: pogorszenie nastąpiło we wtorek rano. Zespół wdrożył nowy silnik rekomendacji w poniedziałek wieczorem.

Korelacja: zbieżność w czasie sugeruje, że przyczyną jest silnik rekomendacji.

Test izolacji: wyłącz silnik rekomendacji. LCP wraca do 2 sekund. Silnik rekomendacji potwierdzony jako przyczyna.

Analiza: silnik rekomendacji wczytuje obrazy produktów do rekomendacji. Obrazy nie są zoptymalizowane (oryginalny rozmiar, bez kompresji). Wczytanie 50 obrazów produktów dodaje do strony 2 megabajty.

Naprawa: zoptymalizuj obrazy silnika rekomendacji. Skompresuj obrazy, użyj leniwego ładowania dla obrazów poniżej pierwszego ekranu. Rozmiar obrazów spada do 500 kilobajtów. LCP poprawia się do 2,2 sekundy.

Wdrożenie: wycofaj silnik rekomendacji, wdróż zoptymalizowaną wersję. LCP wraca do 2,2 sekundy.

Częste problemy z wydajnością i rozwiązania

Problem pierwszy: duży pakiet JavaScriptu

• Objaw: wolny LCP, wolny INP
• Przyczyna: nowa funkcja dodaje kod, pakiet rośnie
• Rozwiązanie: podziel kod funkcji, ładuj funkcję leniwie
• Oczekiwana poprawa: LCP poprawia się o 0,5 sekundy

Problem drugi: wolne zapytania do bazy danych

• Objaw: wolny TTFB
• Przyczyna: zapytanie do bazy zwalnia (brak indeksu, zapytanie łączy wiele tabel)
• Rozwiązanie: dodaj indeks w bazie, zoptymalizuj zapytanie, buforuj wyniki
• Oczekiwana poprawa: TTFB poprawia się o 200 milisekund

Problem trzeci: niezoptymalizowane obrazy

• Objaw: wolny LCP, duże zużycie łącza
• Przyczyna: obrazy są duże (nieskompresowane, zły format)
• Rozwiązanie: skompresuj obrazy, zamień na WebP, użyj obrazów responsywnych
• Oczekiwana poprawa: LCP poprawia się o 1 sekundę

Problem czwarty: skrypty stron trzecich

• Objaw: wolny LCP, strona przestaje reagować
• Przyczyna: zewnętrzna analityka, śledzenie i reklamy spowalniają stronę
• Rozwiązanie: ładuj skrypty stron trzecich leniwie, użyj web workera, ładuj asynchronicznie
• Oczekiwana poprawa: LCP poprawia się o 0,5 sekundy, INP poprawia się o 100 milisekund

Problem piąty: CLS z reklam lub osadzonych treści

• Objaw: układ przesuwa się podczas czytania
• Przyczyna: reklamy ładują się, zajmują miejsce, treść się przesuwa
• Rozwiązanie: zarezerwuj miejsce na reklamy, ładuj reklamy leniwie poniżej pierwszego ekranu
• Oczekiwana poprawa: CLS poprawia się z 0,2 do 0,05

Monitoring do wczesnego wykrywania

Alert na pogorszenie: jeśli LCP przekroczy 2,5 sekundy, powiadom zespół.

Alert na regres: jeśli LCP wzrośnie o więcej niż 0,5 sekundy względem punktu wyjścia, powiadom zespół.

Alert na wpływ biznesowy: jeśli ukończenie rejestracji spadnie o 1 procent, powiadom zespół (może to oznaczać problem z wydajnością).

Prawdziwy przykład: alerty w firmie SaaS

• Alert pierwszy: jeśli LCP przekroczy 2,5 sekundy
• Alert drugi: jeśli wykryto regres wydajności (LCP wzrasta o 50 procent w ciągu jednego dnia)
• Alert trzeci: jeśli Core Web Vitals przechodzą z poziomu dobrego na wymagający poprawy u ponad 5 procent użytkowników
• Alert czwarty: jeśli ukończenie rejestracji spadnie poniżej celu (może to oznaczać problem z wydajnością strony kasy)

Gdy alert się uruchomi: zespół techniczny bada sprawę w ciągu godziny. Przyczyna zostaje ustalona. Poprawka trafia na produkcję tego samego dnia.

Prawdziwy przykład: problem z wydajnością płatności

Objaw: odsetek porzuconych koszyków w kasie wzrósł z 15 procent do 25 procent. Zaczęło się w czwartek.

Analiza: wydajność strony kasy spadła. Czas reakcji przycisku płatności wzrósł z 200 milisekund do 1 sekundy.

Oś czasu: operator płatności zmienił infrastrukturę w czwartek rano.

Przyczyna: operator płatności przeniósł się z Kalifornii do Europy. Opóźnienie sieci od użytkownika do operatora wzrosło o 200 milisekund. Łączny czas przetwarzania płatności wzrósł do 1 sekundy.

Rozwiązanie: użyj węzła brzegowego CDN blisko użytkownika. Przekieruj żądanie płatności przez lokalny węzeł CDN. Węzeł przekazuje je do europejskiego operatora. Opóźnienie sieci maleje. Czas przetwarzania płatności wraca do 200 milisekund.

Efekt: odsetek porzuconych koszyków w kasie wraca do 15 procent.

Wpływ na biznes: 5 tysięcy kas miesięcznie przy 15 procentach porzuceń to 750 straconych konwersji. Przy wartości zamówienia 100 dolarów to 75 tysięcy dolarów straty miesięcznie. Naprawa opóźnienia uratowała firmie 75 tysięcy dolarów miesięcznie.

Najczęstsze pytania