Test obciążeniowy sklepu internetowego przed sezonem: jak go zaplanować

Dobry test obciążeniowy sklepu internetowego zaczyna się od scenariuszy zakupowych. Odpalasz go na kopii sklepu albo w uzgodnionym oknie i zostawiasz sobie zapas czasu na poprawki oraz powtórkę. Połowa września 2026 to ostatni sensowny moment, bo Black Friday wypada 27 listopada, a między pierwszym przebiegiem a kampanią muszą się jeszcze zmieścić zmiany w konfiguracji i kodzie. Pełną listę zadań przed kampanią opisuje nasz tekst o tym, jak przygotować Black Friday w sklepie internetowym. Tutaj bierzemy tylko jeden krok: sprawdzenie wydajności pod ruchem.

Ile ruchu wytrzyma sklep i po co sprawdzać to przed sezonem?

Test pokazuje, przy jakim natężeniu sklep zaczyna zwalniać albo sypać błędami. Lepiej, żebyś dowiedział się tego ty, a nie klienci w dniu kampanii. Zwykły test wydajności sklepu, robiony narzędziem do pomiaru szybkości strony, opisuje wizytę jednego użytkownika. O tym, co się dzieje, gdy wielu kupujących naraz przegląda ofertę, filtruje produkty i składa zamówienia, nie mówi nic. A wtedy o wyniku decydują serwer i baza danych, nie waga grafik.

Celem jest decyzja, nie raport. Po przebiegu masz wiedzieć, co poprawić najpierw i czy obecny serwer wystarczy na sezon. Jeśli wynik do tego nie prowadzi, scenariusz był źle dobrany.

Jakie rodzaje testów obciążeniowych wybrać?

Jeden skrypt nie wystarczy. Różne wzorce ruchu to różne ryzyka, co wprost opisuje dokumentacja k6 o typach testów. W praktyce sklep potrzebuje kilku wariantów:

• Smoke - sprawdza, czy skrypt działa i czy sklep radzi sobie z kilkoma użytkownikami.
• Average-load - odtwarza zwykły dzień sprzedaży. Daje punkt odniesienia dla pozostałych pomiarów.
• Stress - podnosi obciążenie ponad normę, żeby pokazać, gdzie zaczyna się spowolnienie.
• Spike - czyli test skokowy ruchu, symuluje nagły napływ kupujących tuż po starcie kampanii.
• Soak - trzyma stałe obciążenie przez długi czas i ujawnia problemy narastające powoli.

Wzorzec obciążenia niech będzie prosty: narastanie, plateau i wygaszanie. Nazwy typów są umowne i zależą od skali. A narzędzie? Moim zdaniem k6: test obciążeniowy zapisuje się w nim jako skrypt, który można trzymać razem z kodem i uruchamiać ponownie bez zmian.

Które scenariusze zakupowe odtworzyć w teście?

Testuje się pełną ścieżkę zakupu, nie samą stronę główną. Skrypt ma naśladować kolejne kroki prawdziwego klienta:

1. Wejście z kampanii na stronę produktu lub kategorii.
2. Skorzystanie z wyszukiwarki i filtrów.
3. Dodanie produktu do koszyka.
4. Złożenie zamówienia.

Najwięcej zależy tu od koszyka i checkoutu, bo nie są serwowane z cache. Każde żądanie trafia do PHP oraz bazy. Właśnie tam sklep pęka najpierw, nawet gdy strona główna wciąż ładuje się szybko. Proporcje między scenariuszami weź ze statystyk własnego sklepu: jaka część odwiedzających tylko przegląda, a jaka dochodzi do zamówienia. Zgadywanie tych udziałów daje wynik, który opisuje inny sklep niż twój.

Gdzie i kiedy uruchomić test, żeby nie zaszkodzić sprzedaży?

Na kopii sklepu albo w uzgodnionym oknie o niskim ruchu. Nigdy bez wiedzy hostingu. Nieuprzedzony dostawca może potraktować ruch testowy jak atak i go zablokować, co unieważni pomiar, a w gorszym wariancie odetnie też prawdziwych klientów. Na kopii trzeba wyłączyć rzeczywiste płatności i wysyłkę maili do kupujących. Inaczej zamówienia testowe wylądują w skrzynkach i systemach księgowych.

Środowisko testowe powinno odpowiadać produkcji: te same wtyczki, podobna wielkość bazy i ten sam typ serwera. Przy okazji porównaj obecne zasoby z tym, jak dobierać parametry hostingu dla firmy. Okno i zasady testu najłatwiej ustalić, gdy sklep i hosting stron oraz poczty obsługuje ten sam zespół.

Co mierzyć w teście obciążeniowym WooCommerce i co zwykle wymaga poprawy?

Trzy rzeczy: czas odpowiedzi, odsetek błędów i obciążenie bazy danych. Każdą odczytujesz osobno dla każdego scenariusza. Średnia z całego przebiegu ukrywa problem, bo szybkie strony z cache maskują wolny checkout. Test obciążeniowy WooCommerce najczęściej wskazuje te same źródła kłopotów:

• konfigurację cache, która pomija zbyt wiele stron albo jest wyłączona dla zalogowanych,
• ciężkie zapytania do bazy generowane przez wtyczki,
• zadania cron uruchamiane przy wejściach użytkowników zamiast z harmonogramu serwera,
• zewnętrzne skrypty, na które sklep czeka przy każdym żądaniu.

Koszt pojedynczego rozszerzenia da się zmierzyć wprost: w zaleceniach wydajnościowych dla WooCommerce pojawia się rada, żeby testować sklep z włączonym i wyłączonym rozszerzeniem. Bywa też, że przyczyna leży w kodzie, a nie w ustawieniach. Wtedy poprawki wykonuje zespół, który buduje sklepy na platformie WooCommerce, a przy niestandardowych integracjach pomaga tworzenie oprogramowania na zamówienie.

Ponowny test po poprawkach i harmonogram do Black Friday

Każdą poprawkę potwierdza powtórka tego samego scenariusza. Zasada: jedna zmiana na raz, ten sam skrypt, to samo środowisko. Po kilku poprawkach wdrożonych jednocześnie nie będziesz wiedzieć, która zadziałała, a która coś pogorszyła.

Kolejność prac od września:

1. Smoke i average-load, żeby sprawdzić skrypty i ustalić punkt odniesienia.
2. Poprawki wynikające z pierwszych pomiarów, każda z powtórką.
3. Stress i spike, czyli sprawdzenie zapasu oraz reakcji na nagły napływ.
4. Zamrożenie zmian przed kampanią, bez nowych wtyczek i aktualizacji.

Skrypty nie powinny trafić do szuflady po sezonie. Utrzymywane razem z resztą testów, zgodnie z tym, co i kiedy testować automatycznie, przydadzą się przy każdej większej zmianie w sklepie. Wtedy test obciążeniowy sklepu internetowego staje się powtarzalnym elementem przygotowań, a nie jednorazową akcją przed listopadem.

Najczęstsze pytania