Jak przygotować sklep internetowy na Black Friday — technicznie, nie tylko marketingowo

Sklep internetowy rzadko pada w zwykły wtorek o 11:00. Pada w piątek o 20:03 — trzy minuty po tym, jak newsletter z kodem rabatowym trafił do kilkudziesięciu tysięcy skrzynek, a reklamy na Facebooku ruszyły pełną parą. Strona się wczytuje, koszyk się wczytuje, a potem płatność kręci się w nieskończoność. Klient odświeża, płaci drugi raz albo zamyka kartę przeglądarki i kupuje u konkurencji.

W tym roku Black Friday wypada 27 listopada, a Cyber Monday 30 listopada. Promocje trwają jednak cały Black Week, a często zaczynają się już w połowie listopada. Większość poradników skupia się na tym, jak ustawić promocje i kampanie. Ten tekst jest o drugiej połowie przygotowań: o tym, żeby sklep wytrzymał ruch, który te kampanie przyprowadzą.

Liczby pochodzą z danych Shoper z kilkunastu tysięcy sklepów, podsumowania BLIK, raportu Deloitte przygotowanego na zlecenie Google i badań Baymard Institute. Badanie Deloitte opiera się na danych 37 marek i pokazuje korelację, nie był to kontrolowany eksperyment. Wniosek jest jednak spójny z resztą danych: w szczycie sezonu każda sekunda i każdy błąd kosztują więcej niż zwykle. Druga sprawa to telefony: według raportu Gemius z września 2026 roku sklepy internetowe odwiedza średnio 14 mln osób dziennie na telefonie i 3 mln na komputerze (Gemius). Jeśli testujesz sklep tylko na laptopie w biurze, testujesz wersję, której używa mniejszość klientów.

Shopify zaczyna przygotowania pół roku wcześniej: w 2025 roku przeprowadziło pięć testów skali między kwietniem a październikiem (Shopify Engineering). Mały sklep nie potrzebuje takiego programu, ale potrzebuje przynajmniej jednego uczciwego testu. Na to cztery tygodnie wystarczą.

Zdanie „sklep musi wytrzymać duży ruch” niczego nie mówi zespołowi technicznemu. Potrzebne są dwie liczby: ile osób jest jednocześnie w sklepie i ile zamówień na minutę spływa w najbardziej obciążonej godzinie.

Najprostszy sposób, żeby je oszacować:

1. Znajdź najmocniejszą godzinę z zeszłego roku w Google Analytics. Zwykle to któraś godzina wieczorem w Black Friday albo moment wysyłki newslettera.
2. Uwzględnij wzrost sklepu rok do roku: jeśli sprzedaż rośnie o 30%, pomnóż zeszłoroczny szczyt przez 1,3.
3. Dodaj efekt kampanii, których rok temu nie było: nową listę mailingową, influencera, większy budżet reklam.
4. Pomnóż wynik przez dwa jako zapas bezpieczeństwa.

To nie jest nauka ścisła, ale daje cel. Jeśli wychodzi Ci 600 osób jednocześnie i 15 zamówień na minutę, test obciążeniowy ma sprawdzić 1 200 osób i 30 zamówień oraz odpowiedzieć na pytanie, co pęknie pierwsze, gdy pójdziesz jeszcze wyżej.

Zwróć uwagę na kształt ruchu, nie tylko jego wysokość. Newsletter wysłany do całej bazy naraz daje skok w ciągu kilku minut. Wiele sklepów wytrzymuje dużą liczbę odwiedzin rozłożoną w czasie, a przewraca się na pięciominutowym szczycie. Czasem najtańszą „optymalizacją wydajności” jest wysłanie newslettera w trzech partiach co 20 minut.

Zacznij od małego testu. Dokumentacja narzędzia k6 zaleca prostą kolejność: najpierw test dymny, potem coraz większe obciążenie i dłuższy czas trwania. Nie ma sensu puszczać tysiąca wirtualnych klientów, zanim scenariusz przejdzie bez błędów dla pięciu.

Testuj ścieżkę zakupu. Scenariusz testowy powinien robić to, co robi klient: wejść z reklamy na kategorię, użyć filtra, otworzyć produkt, dodać do koszyka, zalogować się albo przejść jako gość, wybrać dostawę i dojść do płatności. Strona główna często siedzi w cache i wytrzyma wszystko. Koszyk i zamówienie zawsze trafiają do bazy danych.

Testuj na środowisku podobnym do produkcji. Test na laptopie programisty albo na najmniejszym serwerze testowym pokaże, że „jest wolno”, ale nie powie, gdzie leży granica na produkcji. Jeśli nie masz osobnego środowiska o tej samej konfiguracji, testuj produkcję w nocy, w uzgodnionym oknie, a scenariusz zatrzymuj tuż przed faktyczną płatnością albo kieruj na konto testowe operatora. Po teście usuń testowe zamówienia, rezerwacje stanów i wysłane maile.

Uprzedź dostawców. Operator płatności, hosting czy firma dostarczająca CDN mogą potraktować nagły ruch z kilku adresów jako atak. Krótki mail przed testem oszczędzi Ci niespodzianek, takich jak blokada ruchu w połowie testu, i nerwów po obu stronach. Na platformach abonamentowych, takich jak Shopify czy Shoper, sprawdź też w regulaminie, czy i na jakich zasadach możesz przeprowadzić test obciążeniowy.

Patrz na właściwe liczby. Średni czas odpowiedzi kłamie, bo ukrywa tych klientów, którzy czekali osiem sekund. Obserwuj czas, w którym mieści się 95% żądań (tzw. p95), odsetek błędów i to, który element systemu zaczyna się dusić pierwszy: procesor, baza danych, pamięć czy kolejka zadań.

Po każdej poprawce testuj jeszcze raz. Usunięcie jednego wąskiego gardła prawie zawsze odsłania następne. Plan na cztery tygodnie powinien zakładać co najmniej dwa pełne cykle: test, poprawki, test.

Google ocenia szybkość strony trzema wskaźnikami Core Web Vitals: czas wyświetlenia największego elementu (LCP) powinien wynosić do 2,5 sekundy, reakcja na interakcję, np. kliknięcie lub dotknięcie (INP) do 200 milisekund, a przesunięcia układu strony (CLS) — nie więcej niż 0,1. Próg musi spełniać co najmniej 75% odsłon, osobno na telefonach i komputerach (web.dev). W 2025 roku wszystkie trzy progi spełniało tylko 48% stron w wersji mobilnej (Web Almanac).

W sklepach często winne są skrypty zewnętrzne. Dla porównania: mediana dla wszystkich stron w sieci, nie tylko sklepów, to 79 żądań do zewnętrznych usług na stronę w wersji mobilnej (Web Almanac) — piksele reklamowe, menedżer tagów, czat, widget opinii, mapa ciepła, narzędzie do testów A/B. Przed sezonem dochodzą kolejne, bo każda kampania chce własnego śledzenia.

Zrób przegląd przed promocją: wypisz wszystkie skrypty, przy każdym zapisz, kto go potrzebuje i do czego, a te, których nikt nie broni, wyłącz. Dla pozostałych przygotuj „tryb awaryjny”, czyli możliwość szybkiego wyłączenia czatu, nagrań sesji czy personalizacji, jeśli sklep zacznie zwalniać pod obciążeniem.

Najtańszy serwer to ten, do którego żądanie w ogóle nie dociera. Strony kategorii, karty produktów, zdjęcia, skrypty i style dla niezalogowanych klientów mogą być serwowane z cache albo z CDN. Koszyk, zamówienie, panel klienta i wszystko, co zależy od konkretnej osoby, muszą trafiać do sklepu.

Przed promocją sprawdź trzy rzeczy:

• Jak długo strona żyje w cache i jak się ją czyści. Jeśli o północy zmieniasz ceny na promocyjne, a cache trzyma strony przez godzinę, część klientów przez godzinę zobaczy stare ceny. Albo, co gorsze, koszyk przeliczy się według innej ceny niż ta na karcie produktu.
• Rozgrzanie cache przed startem. Pierwsze żądanie po wyczyszczeniu cache jest najdroższe. Jeśli wyczyścisz wszystko o 20:00 i o 20:00 wyślesz newsletter, pierwsze tysiące żądań trafią prosto do serwera.
• Stany magazynowe. Produkt, który się wyprzedał, nie może przez godzinę wisieć w cache jako dostępny. Liczba sztuk powinna być pobierana na bieżąco albo przynajmniej sprawdzana przy dodaniu do koszyka.

Pamiętaj też, że CDN to kolejny element, który może zawieść. Dziesięć dni przed Black Friday 2025, 18 listopada, awaria Cloudflare przez kilka godzin powodowała błędy na stronach korzystających z tej usługi (Cloudflare). Ustal z wyprzedzeniem, czy da się w razie potrzeby szybko skierować ruch bezpośrednio na serwer i kto ma do tego dostęp.

Z cenami wiąże się jeszcze jeden wymóg, tym razem prawny. Od 2023 roku sklep, który ogłasza obniżkę, musi pokazać obok niej najniższą cenę z 30 dni przed obniżką, z uwzględnieniem nawet cen obowiązujących przez jeden dzień, osobno dla każdego kanału sprzedaży (UOKiK). To w praktyce wymaganie techniczne: sklep musi przechowywać historię cen i poprawnie ją wyliczać, także dla produktów, których cenę zmieniano ręcznie albo importem. Sprawdź to przed startem promocji na kilku produktach, zwłaszcza tych, których cenę zmieniano importem.

Płatność to miejsce, w którym błąd kosztuje najwięcej, bo klient był już zdecydowany. Cztery rzeczy do omówienia z zespołem technicznym:

Druga metoda płatności gotowa do włączenia. Operatorzy płatności też mają gorsze dni: 2 kwietnia 2026 roku PayU przez około godzinę walczyło z atakiem DDoS, a metody płatności były czasowo niedostępne (Wprost). Możliwość szybkiego przełączenia klientów na innego operatora ratuje wieczór. Konfigurację trzeba przygotować i przetestować wcześniej — w piątek wieczorem nikt nie zakłada nowego konta u operatora.

Ochrona przed podwójną płatnością. Gdy płatność długo się nie potwierdza, klienci klikają ponownie. Sklep powinien rozpoznać, że to ta sama transakcja, zamiast tworzyć drugie zamówienie i drugi raz pobierać pieniądze. Technicznie służy do tego tzw. klucz idempotencji przy każdej próbie płatności.

Powiadomienia od operatora przyjmowane przez kolejkę. Operator płatności informuje sklep o opłaceniu zamówienia osobnym żądaniem. Jeśli sklep jest w tym momencie przeciążony i go nie przyjmie, zamówienie może utknąć jako nieopłacone, choć pieniądze zeszły z konta klienta. Przyjmuj takie powiadomienia od razu i przetwarzaj je z kolejki, a co kilkanaście minut sprawdzaj w API operatora status zamówień, które wiszą jako nieopłacone.

Limity zewnętrznych usług. Generowanie etykiet kurierskich, wysyłka SMS i systemy rabatowe mają swoje limity zapytań. Sprawdź je przed szczytem.

Wiele awarii w szczycie sezonu nie wynika z samego ruchu, tylko ze zmian wprowadzonych tuż przed nim. Zespół SRE w Google szacuje, że około 70% awarii powodują zmiany wprowadzane w działającym systemie (Google SRE). Nowa wtyczka, „mała poprawka” w koszyku, aktualizacja motywu w czwartek wieczorem. Dlatego na mniej więcej tydzień przed startem Twojej promocji ogłoś zamrożenie zmian (jeśli ruszasz 16 listopada, zamrażasz zmiany od 9 listopada): na produkcję trafiają wyłącznie poprawki błędów, które blokują sprzedaż — i tylko po akceptacji osoby odpowiedzialnej za sklep.

Plan awaryjny nie musi być długim dokumentem. Wystarczy jedna strona, na której jest:

• kto ma dyżur od piątku do poniedziałku, także w nocy — z numerami telefonów, a nie tylko adresami e-mail,
• jak wycofać ostatnie wdrożenie — sprawdzone w praktyce, a nie „powinno się dać”,
• kontakty do hostingu, operatora płatności i agencji, która prowadzi kampanie, żeby w razie problemu można było wstrzymać reklamy,
• co robimy, gdy sklep nie wytrzymuje, na przykład włączamy stronę z kolejką albo komunikat o chwilowym przeciążeniu zamiast błędu serwera,
• gotowy komunikat dla klientów na stronę i do mediów społecznościowych.

Jeśli Twój sklep działa w chmurze, sprawdź też, czy automatyczne skalowanie ma rozsądny limit górny i czy ktoś dostanie powiadomienie o nagłym wzroście kosztów. Skalowanie bez limitu chroni przed awarią, ale potrafi wygenerować rachunek, którego nikt się nie spodziewał.

Weekend promocyjny to najlepszy test obciążeniowy, jaki dostaniesz w tym roku za darmo. Zapisz, przy jakim ruchu sklep zaczął zwalniać, które alerty były przydatne, a które tylko hałasowały, i co trzeba było naprawiać na żywo. Scenariuszy testowych i planu awaryjnego nie wyrzucaj. Przydadzą się za kilka tygodni, przed świątecznym szczytem zamówień.

Jeśli w trakcie przygotowań okaże się, że sklep potrzebuje stałej opieki nad infrastrukturą, przeczytaj, jak działa DevOps as a Service, czyli utrzymanie z dyżurem i reakcją przy awarii na produkcji. Zakres i stawki znajdziesz na stronie usług DevOps. A jeśli dopiero planujesz nowy sklep, zobacz, jak w trzy tygodnie powstała pierwsza wersja sklepu Bezuma.