Jak nie pozwolić sklepowi zwolnić z powrotem

Monitoring wydajności PrestaShop jest tym, co odróżnia sklep, który został przyspieszony raz, od sklepu, który jest szybki na stałe. Bez niego prędkość wycieka w tempie, w jakim firma się rozwija: nowy moduł marketingowy dokłada skrypty, kampania wymusza baner z ciężką grafiką, integracja dopisuje atrybuty i listing zaczyna generować więcej zapytań. Po dwóch kwartałach wskaźniki wracają tam, gdzie były przed pracami, a nikt nie potrafi wskazać momentu, w którym to się stało.

Ten tekst opisuje, co mierzyć na co dzień, jakie progi ustawić i jak powiązać spadek wydajności z konkretną zmianą, zamiast szukać przyczyny po omacku.

Dlaczego kwartalny przegląd nie wystarcza

Przegląd raz na kwartał wykrywa problem po fakcie, gdy między przyczyną a objawem leży kilkadziesiąt zmian w sklepie. Ustalenie, która z nich odpowiada za spadek, zajmuje wtedy więcej czasu niż samo jego usunięcie.

Monitoring odwraca tę logikę. Nie pytasz „dlaczego sklep zwolnił przez ostatnie trzy miesiące”, tylko dostajesz sygnał tego samego dnia, w którym wdrożono zmianę. Przyczyna jest wtedy oczywista, bo w tym dniu wydarzyła się jedna rzecz.

Druga różnica dotyczy tego, co w ogóle da się zauważyć. Spadek o kilka procent tygodniowo jest niewidoczny dla człowieka odwiedzającego sklep codziennie, bo przyzwyczajenie działa szybciej niż pamięć. Wykres pokazuje go od razu.

Monitoring wydajności PrestaShop: cztery liczby, nie czterdzieści

Systemy monitoringu potrafią zbierać setki metryk i to jest ich największa pułapka: pulpit z czterdziestoma wykresami nie jest oglądany przez nikogo. Cztery liczby wystarczą do prowadzenia sklepu.

Pierwsza metryka pochodzi od użytkowników i jest tą, która realnie się liczy. Trzy pozostałe zbierasz syntetycznie, w powtarzalnych warunkach, i one służą do wskazania przyczyny. Ta para jest komplementarna: dane od użytkowników mówią, że jest gorzej, dane syntetyczne mówią dlaczego.

Warto dołożyć piątą pozycję, która nie jest metryką wydajności, ale ratuje najwięcej: liczbę błędów 500 i przekroczeń limitu czasu. Sklep, który zwraca błąd co kilkaset żądań, traci zamówienia w sposób niewidoczny w analityce, bo sesja zakończona błędem serwera nie generuje zdarzenia.

Progi i alerty, które nie zamieniają się w szum

Alert, który odzywa się codziennie, przestaje być alertem po tygodniu. Zasada jest jedna: powiadomienie ma oznaczać, że ktoś musi coś zrobić. Wszystko poniżej tego progu należy do wykresu, nie do powiadomienia.

• LCP na karcie produktu przekracza 2,5 s w danych z realnego ruchu. To próg z Core Web Vitals i naturalna granica.
• Czas odpowiedzi serwera rośnie wobec średniej z poprzedniego tygodnia, a nie wobec wartości bezwzględnej. Porównanie do własnej historii jest uczciwsze niż do cudzego wzorca.
• Liczba zapytań na listingu wzrosła skokowo. Skok zawsze oznacza konkretną zmianę i zawsze warto ją znaleźć.
• Pojawiły się błędy 500. Ten alert powinien być natychmiastowy i trafiać do osoby, która może zareagować, a nie do wspólnej skrzynki.

Osobno warto ustawić kontrolę dostępności sklepu z zewnątrz, sprawdzającą nie tylko stronę główną, ale też jedną kartę produktu i stronę koszyka. Sklep potrafi odpowiadać poprawnie na stronie głównej przy jednocześnie zepsutym checkoucie, a monitoring pilnujący wyłącznie adresu domeny tego nie pokaże.

Jak powiązać spadek z konkretną zmianą

Sam wykres mówi, że coś się pogorszyło. Żeby wiedzieć co, potrzebujesz drugiej osi: zapisu zmian w sklepie.

Nie wymaga to narzędzia. Wystarczy prosty dziennik, do którego trafia data, opis zmiany i osoba odpowiedzialna. Wdrożenie modułu, aktualizacja motywu, start kampanii z nowym banerem, import dużej partii produktów, zmiana konfiguracji serwera. Jedna linia na wpis.

Nałożenie tego dziennika na wykres wydajności zamienia diagnozę z godzin w minuty. W praktyce ta sama lista odpowiada też na pytanie, kto ma się zająć problemem, bo przy każdej zmianie stoi nazwisko.

Najczęstsze zdarzenia, po których warto sprawdzić metryki tego samego dnia:

• Instalacja albo aktualizacja modułu. Najczęstsza pojedyncza przyczyna regresji.
• Nowy skrypt zewnętrzny. Piksel, czat, narzędzie do testów. Dokładane zwykle poza kontrolą techniczną.
• Kampania z nową grafiką. Baner na stronie głównej bywa najcięższym plikiem w sklepie i mierzy LCP.
• Import produktów. Nowe zdjęcia w oryginalnej rozdzielczości i nowe wartości atrybutów.
• Wdrożenie zmian w motywie. Sprawdź przy tej okazji, czy cache nie został przypadkiem wyłączony podczas diagnozy.

Czym to mierzyć

Dobór narzędzi jest prostszy, niż sugeruje rynek, bo potrzebujesz trzech warstw, a nie trzynastu produktów.

Pierwszą warstwę masz zwykle bez dodatkowych kosztów, bo dane o wskaźnikach użytkowników udostępnia narzędzie dla webmasterów podpięte do sklepu. Druga to pomiar wykonywany w stałych warunkach, ręcznie albo automatycznie. Trzecia to system monitoringu odpytujący sklep z zewnątrz co kilka minut.

Systemy monitoringu potrafią też zbierać metryki z wnętrza serwera: obciążenie procesora, zajętość pamięci, liczbę zapytań do bazy i czas ich wykonania. To wartościowe przy diagnozie, ale nie zaczynaj od tego. Sklep, w którym nikt nie zna LCP karty produktu, nie potrzebuje wykresu obciążenia procesora; potrzebuje pierwszej warstwy.

Uwaga na koszt utrzymania samego monitoringu. Każde narzędzie dokłada swój agent albo swój skrypt, a skrypt monitorujący wydajność, który sam ją pogarsza, jest sytuacją częstszą, niż mogłoby się wydawać. Sprawdź wpływ narzędzia na czas wyświetlania po jego wdrożeniu, tak samo jak sprawdzasz każdy inny skrypt.

Budżet wydajnościowy zamiast dobrych chęci

Najskuteczniejszy mechanizm utrzymania prędkości nie jest techniczny, tylko organizacyjny. Polega na ustaleniu z góry, ile sklepowi wolno ważyć i jak długo się ładować, i traktowaniu tych wartości jak limitu, a nie jak życzenia.

Budżet zapisuje się w kilku liczbach, na przykład: LCP karty produktu poniżej 2,5 s na telefonie, łączna waga strony poniżej ustalonej wartości, liczba skryptów zewnętrznych nie większa niż uzgodniona. Wartości dobierasz z własnego pomiaru, nie z cudzego wzorca.

Reguła, która sprawia, że to działa: nowy element wchodzi tylko wtedy, gdy mieści się w budżecie, albo gdy coś innego z niego wychodzi. Bez tej wymiany budżet zamienia się w dokument, do którego nikt nie zagląda. Z nią rozmowa o dołożeniu kolejnego narzędzia marketingowego przestaje być sporem o przekonania i staje się pytaniem, co w zamian.

Właścicielem budżetu powinna być osoba decydująca o sklepie, nie wykonawca techniczny. Wykonawca może pilnować liczb, ale nie może odmówić działowi marketingu dołożenia narzędzia, bo to nie jego decyzja. Wskazanie tej osoby jest w praktyce ważniejsze niż same wartości.

Kontrola przy każdym wdrożeniu

Monitoring wykrywa problem po fakcie. Taniej jest nie wpuścić go na produkcję. Trzy sprawdzenia, każde na kilka minut, wykonywane przy każdym wdrożeniu.

Pomiar przed i po dla nowego modułu. Czas generowania strony i liczba zapytań do bazy, na środowisku testowym. Moduł, który nie zarabia na swój koszt, nie wchodzi. To jest moment, w którym decyzja jest tania; po trzech miesiącach użytkowania usunięcie modułu jest już rozmową o procesach, nie o wydajności.

Kontrola cache. Dwa pobrania tej samej strony i porównanie czasów. Kwadrans, a wyłapuje sytuację, w której nowy element zaczął omijać buforowanie. To najczęstsza regresja po wdrożeniu i jednocześnie najłatwiejsza do przeoczenia, bo sklep działa poprawnie, tylko wolniej.

Pełna ścieżka zakupowa. Od wyszukania produktu przez koszyk po płatność testową, z otwartą konsolą błędów przeglądarki. Sprawdzenie samej strony głównej niczego nie dowodzi, bo najbardziej złożone skrypty żyją w checkoucie.

Sposób wyceniania pojedynczego modułu i porządkowania tej warstwy rozkładamy w tekście o optymalizacji modułów PrestaShop.

Zasady, które utrzymują prędkość bez nadzoru

Najskuteczniejszy monitoring to ten, którego nie trzeba czytać, bo zmiany pogarszające wydajność nie wchodzą do sklepu. Cztery reguły, każda kosztuje minuty przy wdrożeniu i oszczędza dni później.

• Ustalony maksymalny wymiar zdjęcia przy wgrywaniu. To najczęstsza droga, którą prędkość wycieka z powrotem, i jedyna reguła z tej listy dotycząca osób spoza działu technicznego.
• Nowy moduł wchodzi przez środowisko testowe, z pomiarem przed i po.
• Każdy skrypt zewnętrzny ma właściciela po stronie firmy i pytanie, na które odpowiada. Bez właściciela wychodzi przy najbliższym przeglądzie.
• Baner kampanijny przechodzi kontrolę wagi przed publikacją, tak jak przechodzi korektę tekstu.

W sklepach rozwijanych intensywnie ten nadzór zamyka się w stałej opiece technicznej, gdzie przegląd wydajności jest częścią umowy, a nie osobnym zleceniem. Zakres takiej współpracy opisujemy przy okazji wsparcia technicznego PrestaShop.

Kto na to patrzy i co robi z wynikiem

Monitoring bez przypisanej osoby jest zbiorem wykresów, które nikt nie ogląda. To najczęstszy powód, dla którego wdrożone narzędzia przestają być używane po kwartale.

Podział, który się sprawdza, opiera się na trzech rolach i żadna nie wymaga pełnego etatu.

• Alerty o błędach i niedostępności trafiają do osoby, która może zareagować technicznie, i to natychmiast. Wspólna skrzynka nie jest adresatem, bo odpowiedzialność rozmywa się między odbiorcami.
• Tygodniowy rzut oka na wskaźniki należy do osoby prowadzącej sklep. Pięć minut, cztery liczby, pytanie „czy coś odstaje od poprzedniego tygodnia”.
• Miesięczny raport z rekomendacją idzie do osoby decydującej o budżecie. To ona rozstrzyga, czy usunąć narzędzie marketingowe albo sfinansować zmianę hostingu.

Trzeci punkt jest tym, który zamyka pętlę. Bez adresata decyzyjnego monitoring wykrywa regresje, których nikt nie ma mandatu usunąć, a zespół techniczny raportuje w próżnię. Po kilku takich cyklach przestaje raportować.

Od czego zacząć, jeśli nie masz nic

Pełny zestaw z trzema warstwami i dziennikiem zmian brzmi jak projekt. Nie musi nim być. Kolejność wdrażania, w której każdy krok ma sens samodzielnie:

1. Alert o niedostępności sklepu. Kilka minut konfiguracji, a chroni przed najdroższym możliwym zdarzeniem. Sprawdzaj stronę główną, jedną kartę produktu i koszyk.
2. Cotygodniowy odczyt wskaźników od użytkowników. Dane zwykle już masz, wystarczy wpisać do kalendarza pięć minut i zapisywać wartości.
3. Dziennik zmian. Jedna linia na wdrożenie. Bez niego wykresy pokazują, że coś się stało, ale nie co.
4. Pomiar przed i po przy każdym nowym module. Zamienia dyskusję o module w rozmowę o liczbach.
5. Miesięczny raport z jedną rekomendacją. Dopiero teraz, gdy masz z czego go złożyć.

Pierwsze trzy kroki mieszczą się w jednym popołudniu i nie wymagają wykonawcy technicznego. To zwykle wystarcza, żeby wyłapać regresje, zanim staną się trwałe, a taki jest cały cel tego obszaru.

Jedna uwaga o progach na start: nie ustawiaj ich od razu na wartościach docelowych, jeśli sklep ich dziś nie spełnia. Alert odzywający się nieprzerwanie od pierwszego dnia zostanie wyciszony w tydzień i nikt do niego nie wróci. Ustaw próg nieco powyżej obecnego stanu, żeby wyłapywał pogorszenia, i zaciskaj go w miarę poprawy.

Raport, który ktoś przeczyta

Raz w miesiącu warto zamknąć te dane w jednej stronie. Nie w pulpicie z wykresami, tylko w krótkim zestawieniu, które przeczyta osoba decydująca o budżecie.

• cztery metryki, wartość dziś i miesiąc temu
• zmiany wdrożone w tym okresie, z dziennika
• wykryte regresje i co z nimi zrobiono
• jedna rekomendacja na kolejny miesiąc

Ostatni punkt jest tym, który zamienia monitoring w narzędzie decyzyjne zamiast archiwum. Bez rekomendacji raport jest zbiorem liczb, po których nic się nie dzieje.

Metodologię pomiarów i sposób liczenia progów opisuje dokumentacja Google na web.dev. Warto do niej zajrzeć przed ustawieniem alertów, żeby odróżnić dane od realnych użytkowników od wyniku pojedynczego testu, bo alert oparty na tym drugim będzie się odzywał bez powodu.

Monitoring domyka cykl, który zaczyna się od pomiaru i przechodzi przez cache, serwer, obrazy i skrypty. Kolejność tych prac oraz to, co robić, gdy sklep jest już szybki, porządkuje przewodnik o optymalizacji PrestaShop. Usługowo obszar zamyka optymalizacja wydajności PrestaShop.