Skalowanie analityki wydajności na wiele produktów: zarządzanie wydajnością w dużej firmie

Rozdziel odpowiedzialność za wydajność między zespoły. Ustal standardy. Monitoruj zgodność. Skaluj pomiar wydajności na wiele produktów i platform.

Wersja robocza

Zarządzanie wydajnością jednej strony jest wykonalne. Zarządzanie wydajnością dziesięciu stron, pięciu aplikacji mobilnych i wielu mikroserwisów jest złożone.

Jedna strona: panel pokazuje LCP, CLS, INP. Zespół skupia się na jednej stronie naraz.

Duża firma: panel pokazuje setki stron, wiele produktów, wiele platform. Zespół musi ustalać priorytety.

Skalowanie analityki wydajności oznacza: wybór, co mierzyć, wybór, co optymalizować, i rozdzielenie odpowiedzialności między zespoły.

Przykład: firma ma pięć produktów (platforma internetowa, aplikacja mobilna, panel, narzędzie analityczne, API). Każdy produkt ma inny profil wydajności. Każdym produktem zajmuje się inny zespół. Centralny zespół wydajności nie zoptymalizuje wszystkiego. Rozwiązanie: ustalić standardy wydajności, każdy zespół odpowiada za wydajność swojego produktu, a centralny zespół monitoruje wydajność zbiorczą.

Wybór tego, co mierzyć w dużej firmie

Mierz tylko ścieżki krytyczne. Platforma e-commerce: strona główna, strona produktu, kasa (krytyczne). Blog, strona o firmie (niekrytyczne). Skup się na ścieżkach krytycznych.

Mierz według linii produktów. Platforma SaaS: strona rejestracji, panel, strona ustawień. Każdy zespół odpowiada za swoje strony. Każdy zespół śledzi swoją wydajność.

Mierz według wpływu na biznes. Najważniejsze są strony, które generują przychody. Strony z małym ruchem są mniej ważne. Skup się na stronach przynoszących przychody.

Prawdziwy przykład: firma z trzema liniami produktów:

  • Produkt A (e-commerce): strona główna, produkt, kasa, wyszukiwarka
  • Produkt B (SaaS): rejestracja, panel, ustawienia, integracje
  • Produkt C (treści): strona główna bloga, artykuł, komentarze, powiązane artykuły

Priorytet pomiaru:

  • Produkt A (największy ruch, największe przychody): mierz wszystkie strony
  • Produkt B (duży ruch, duże przychody): mierz strony krytyczne (rejestracja, panel)
  • Produkt C (mały ruch, małe przychody): mierz tylko stronę główną

Rozdzielanie odpowiedzialności za wydajność

Centralny zespół ustala standardy. Każdy zespół odpowiada za wydajność swojego produktu.

Standardy: wszystkie strony muszą mieć LCP poniżej 2,5 sekundy, CLS poniżej 0,1 i INP poniżej 200 milisekund.

Model odpowiedzialności:

  • Zespół produktu A: odpowiada za wydajność strony głównej, produktu, kasy, wyszukiwarki
  • Zespół produktu B: odpowiada za wydajność rejestracji, panelu, ustawień
  • Zespół produktu C: odpowiada za wydajność strony głównej bloga
  • Centralny zespół wydajności: monitoruje zgodność, alarmuje o regresach, dostarcza narzędzia

Prawdziwy przykład: firma SaaS z trzema zespołami inżynierów.

Standardy (ustalone przez centralny zespół wydajności):

  • Cel LCP: 2 sekundy (cele dla poszczególnych produktów mogą się różnić, ale punktem wyjścia jest 2 sekundy)
  • Cel CLS: 0,05
  • Cel INP: 150 milisekund

Odpowiedzialność zespołów produktowych:

  • Zespół platformy: panel musi utrzymać LCP poniżej 2 sekund
  • Zespół integracji: strona integracji musi utrzymać LCP poniżej 2,5 sekundy
  • Zespół analityki: strona analityki musi utrzymać LCP poniżej 2 sekund

Każdy zespół mierzy własne strony. Panel alarmuje, gdy strony zespołu przekroczą standardy. Zespół odpowiada za wynik.

Agregowanie wydajności w produktach

Panel zbiorczy pokazuje: wszystkie produkty, wszystkie strony, zgodność ze standardami.

Panel pokazuje odsetek produktów spełniających standard: 90 procent stron ma LCP poniżej 2,5 sekundy. Strefa zielona.

Panel pokazuje, które produkty nie spełniają standardu: produkt B ma 80 procent zgodności (dwie strony przekraczają standard). Strefa żółta.

Raport dla zarządu: wydajność zbiorcza jest dobra (90 procent stron zgodnych). Jeden produkt wymaga uwagi (produkt B).

Działanie: zespół produktu B dostaje alert. Zespół bada sprawę. Zespół optymalizuje niezgodne strony.

Prawdziwy przykład: zbiorcza wydajność firmy z trzema produktami.

Produkt A (e-commerce):

  • Strona główna: LCP 1,2 s (zgodna)
  • Strona produktu: LCP 1,8 s (zgodna)
  • Kasa: LCP 2,1 s (zgodna)
  • Wyszukiwarka: LCP 2,4 s (zgodna)
  • Zgodność: 100 procent

Produkt B (SaaS):

  • Rejestracja: LCP 1,9 s (zgodna)
  • Panel: LCP 2,6 s (niezgodny)
  • Ustawienia: LCP 2,5 s (niezgodne)
  • Zgodność: 66 procent

Produkt C (treści):

  • Strona główna bloga: LCP 2,3 s (zgodna)
  • Zgodność: 100 procent

Łącznie: 88 procent zgodności we wszystkich produktach.

Raport dla zarządu: dwa z trzech produktów w pełni zgodne. Produkt B wymaga uwagi. Zespół pracuje nad poprawą wydajności panelu i ustawień.

Standardy wydajności dla typów urządzeń i regionów

Standardy mogą zależeć od kontekstu. Standardy dla komputerów różnią się od mobilnych. Standardy dla USA różnią się od międzynarodowych.

Cel LCP na komputerach: 2 sekundy (szybki internet, szybki procesor).

Cel LCP na telefonach: 3 sekundy (wolniejszy internet, wolniejszy procesor).

Cel LCP w USA: 2 sekundy (ogólnie szybki internet).

Cel LCP międzynarodowy: 3 sekundy (zróżnicowane prędkości internetu).

Prawdziwy przykład: globalna firma SaaS z wdrożeniem w wielu regionach.

Standard LCP według regionu:

  • USA: 1,8 sekundy (cel)
  • UE: 2,2 sekundy (cel, wolniejszy internet niż w USA)
  • APAC: 2,5 sekundy (cel, bardziej zmienny internet)

Wydajność według regionu (stan obecny):

  • USA: 1,5 sekundy (dobrze, powyżej celu)
  • UE: 2,3 sekundy (na poziomie celu, potrzebna niewielka poprawa)
  • APAC: 3,0 sekundy (poniżej celu, wymaga poprawy)

Działanie: zespół APAC (albo centralny zespół wydajności, jeśli nie ma zespołu regionalnego) optymalizuje wydajność w APAC. Skupienie: optymalizacja CDN dla regionów APAC, optymalizacja obrazów pod mniejszą przepustowość.

Najczęstsze pytania

Jak ustalić różne standardy wydajności dla różnych produktów?

Oprzyj się na znaczeniu dla biznesu i oczekiwaniach użytkowników. Produkt generujący najwięcej przychodów: najbardziej ambitny cel. Produkt generujący mniej przychodów: łagodniejszy cel. Przykład: kasa w e-commerce jest najbardziej krytyczna (generuje przychody). Cel: 1,5 sekundy. Treści bloga są mniej krytyczne. Cel: 2,5 sekundy. Dzięki kreatorowi stron WEMASY możesz to ustawić bezpośrednio na swojej stronie.

Czy centralny zespół wydajności ma optymalizować wszystkie produkty, czy tylko ustalać standardy?

Ustalać standardy i monitorować. Optymalizację zostaw zespołom produktowym. Centralny zespół zapewnia narzędzia, wsparcie i eskalację. Jeśli zespół produktu nie spełnia standardu, centralny zespół pomaga. Ale codzienna optymalizacja to odpowiedzialność zespołu produktu.

Jak rozwiązywać konflikty między rozwojem produktu a wymaganiami wydajności?

Wydajność to część wymagań produktu. Nowa funkcja musi spełniać standardy wydajności. Jeśli funkcja dodaje kod, który pogarsza wydajność, nie zostaje zatwierdzona, dopóki nie zostanie zoptymalizowana. Wydajność nie podlega negocjacjom (chyba że zarząd wyraźnie obniży jej priorytet z powodów biznesowych).

Czy mierzyć wydajność stron o małym ruchu?

Nie. Skup się na stronach o dużym ruchu i dużym wpływie. Strony o małym ruchu nie są warte wysiłku optymalizacji. O priorytecie decyduje ruch razem z wpływem na biznes. Mierz tam, gdzie wpływ jest największy.

Jak uwzględnić różnice w szybkości sieci między regionami?

Ustal różne cele dla regionów. USA ma szybkie sieci. Ustal ambitny cel (1,5 sekundy). Regiony międzynarodowe mają zróżnicowane sieci. Ustal realistyczne cele (2-3 sekundy). Mierz wydajność według regionów. Alarmuj, gdy region nie osiąga własnego celu (a nie celu bezwzględnego).

Czy włączyć budżety wydajności do potoku wdrożeń wszystkich zespołów?

Tak. Sprawdzaj budżet wydajności przed wdrożeniem. Jeśli kod zespołu przekracza budżet, wdrożenie jest blokowane. To zapobiega regresom. Zapewnia też odpowiedzialność (zespół musi zoptymalizować kod przed wdrożeniem).

Wykorzystaj to od razu
na własnej stronie.

Zacznij za darmo z WEMASY i zbuduj stronę w kilka minut.