Wolny sklep internetowy a sprzedaż: co mówią dane i co mierzyć w PrestaShop i WooCommerce

Wolny sklep internetowy traci sprzedaż, ale nie dlatego, że "strona główna ładuje się 3 sekundy". Najwięcej kosztują wolne strony, których nie widać w zwykłym teście: karta produktu, koszyk i kolejne kroki zamówienia, które omijają cache i obciążają serwer przy każdym kliknięciu. W IThandy mierzę szybkość sklepów na PrestaShop, WooCommerce i Magento od strony klienta, i ten artykuł zbiera to, co warto wiedzieć, zanim wydasz pieniądze na "przyspieszanie".

Co mówią dane o szybkości sklepu i konwersji (bez mitów)

Szybkość ma udowodniony wpływ na konwersję w e-commerce, ale rzetelnych, aktualnych badań jest niewiele i każde mierzy coś innego. Zamiast jednej "magicznej" liczby warto znać trzy źródła i wiedzieć, czego dotyczą.

• Deloitte i Google, "Milliseconds make millions" (web.dev): poprawa szybkości strony mobilnej o 0,1 s zwiększyła konwersję o 8,4% w sklepach (retail) i o 10,1% w turystyce, a klienci sklepów wydawali o 9,2% więcej. Ważny warunek: efekt pojawiał się, gdy przyspieszenie objęło całą ścieżkę klienta i kilka wskaźników naraz, a nie jedną stronę.
• Portent 2022 (portent.com): strony sklepów ładujące się w 1 s konwertowały 2,5 raza lepiej niż strony ładujące się w 5 s. W tym samym badaniu 86% zmierzonych stron B2C e-commerce ładowało się w 5 s lub szybciej (w 2019 r. 81%).
• Gemius 2025 (omówienie Przelewy24): wśród barier zakupów na telefonie 33% wskazuje niewygodne formularze, 27% wolne połączenie z internetem, 25% brak dopasowania strony do urządzenia. Uwaga: 27% dotyczy łącza kupującego, nie szybkości sklepu. To jednak argument za lekkimi stronami, bo ciężki sklep na słabym zasięgu działa jeszcze gorzej.

Do tego kontekst: w sezonie świątecznym 2025 w USA 56,4% transakcji online odbyło się na smartfonach (Adobe). Mierz więc wersję mobilną, nie tylko komputer w biurze.

Czego nie cytuję: często powtarzane "100 ms opóźnienia to 1% sprzedaży Amazona" pochodzi z 2006 r., a przykład Shopzilla z 2008 r. To inne czasy, inne przeglądarki i inne sklepy. Nie opieraj na nich decyzji budżetowych.

Trzy rodzaje "wolno": serwer, przeglądarka, checkout

"Sklep jest wolny" to trzy różne problemy, które naprawia się zupełnie inaczej. Zanim cokolwiek zmienisz, ustal, który z nich masz.

1. Wolny serwer (TTFB). Przeglądarka długo czeka na pierwszy bajt HTML. Przyczyny: PHP, baza danych, za słaby hosting, za dużo modułów lub wtyczek, brak OPcache. Web.dev podaje orientacyjnie, że TTFB do 0,8 s to dobry wynik (web.dev, TTFB). Najbardziej cierpią strony bez cache: koszyk, zamówienie, wyszukiwarka, konto klienta.

2. Wolna przeglądarka (Core Web Vitals). HTML przychodzi szybko, ale strona długo się rysuje albo reaguje z opóźnieniem. Google uznaje za dobre: LCP do 2,5 s, INP do 200 ms, CLS do 0,1, liczone dla 75% odsłon (web.dev, Web Vitals). INP zastąpił FID jako wskaźnik Core Web Vitals 12 marca 2024 r. Przyczyny: ciężkie zdjęcia, za dużo JavaScriptu, skrypty marketingowe, czcionki, slidery.

3. Wolne kroki zamówienia. Strona zamówienia otwiera się szybko, ale wybór dostawy, płatności czy kodu rabatowego "kręci się" kilka sekund. Każdy taki krok to osobne żądanie AJAX do modułu przewoźnika lub bramki, czasem do zewnętrznego API (mapa paczkomatów InPost, iframe płatności). Tego nie pokaże żaden test strony głównej.

Cache przyspiesza stronę główną, a koszyk zostaje wolny

Cache stron sprawia, że sklep wygląda na szybki w testach, choć klient w koszyku czeka kilka sekund. Moduły i serwery cache (JPresta Page Cache w PrestaShop, LiteSpeed Cache w WooCommerce, Varnish i Full Page Cache w Magento, Cloudflare) podają gotowy HTML gościom. Ale koszyk, zamówienie, wyszukiwarka i strony zalogowanego klienta z definicji go omijają, bo są inne dla każdej osoby.

Skutek: PageSpeed strony głównej daje świetny wynik, a pierwsze kliknięcie "Dodaj do koszyka" trafia do PHP, który odpowiada w 3 s. Co gorsza, cache potrafi pokazywać działającą stronę główną, gdy PHP już w ogóle nie odpowiada. Dlatego w monitoringu zawsze mierzę dwie rzeczy: stronę "jak klient" (z cache) i serwer z pominięciem cache. Więcej o tym w artykule o tym, jak cache sklepu ukrywa awarię.

Gdzie sklepy tracą czas: PrestaShop, WooCommerce, Magento

Każda platforma ma swoje typowe "hamulce" i warto zacząć od nich, zanim kupisz mocniejszy serwer.

PrestaShop

• Parametry zaawansowane -> Wydajność: kompilacja szablonów Smarty ustawiona na "Nigdy nie kompiluj" na produkcji (po wdrożeniu zmian czyścisz cache ręcznie).
• CCC (łączenie i kompresja CSS i JS): włącz, ale przetestuj motyw, bo słabsze motywy potrafią się po nim rozjechać.
• OPcache włączony dla PHP-FPM, który obsługuje sklep, a nie tylko dla PHP w konsoli. To częsta pułapka na hostingach.
• Za dużo modułów podpiętych pod te same hooki, zwłaszcza na karcie produktu i w koszyku.
• JPresta Page Cache dla gości, ale koszyk i zamówienie i tak idą bez cache.
• Indeks wyszukiwarki: przebudowany i aktualny, inaczej wyszukiwanie jest wolne albo puste.

WooCommerce

• Rozdęta tabela opcji z autoload (wtyczki, które zostawiły dane po odinstalowaniu).
• Za dużo wtyczek ładujących skrypty na każdej stronie, także w checkoutcie.
• Żądania wc-ajax i Store API nie są cache'owane, więc to one mówią prawdę o serwerze.
• LiteSpeed Cache i podobne: koszyk, zamówienie i "Moje konto" muszą być wykluczone z cache, inaczej klient widzi cudzy koszyk albo checkout się psuje.
• Zaległości w Action Scheduler (tysiące zadań w kolejce) spowalniają cały panel i sklep.

Magento 2

• Full Page Cache i Varnish dla gości, ale checkout i koszyk to czysty PHP.
• Indeksery w trybie "Update by Schedule" i działający cron, inaczej ceny i stany odświeżają się z opóźnieniem, a zapytania są cięższe.
• Rozszerzenia dostaw i płatności, które w checkoutcie wołają zewnętrzne API.

Platformowe szczegóły monitoringu: monitoring sklepu PrestaShop z testem zamówienia i monitoring WooCommerce.

Mediana i 95. percentyl zamiast średniej

Średni czas odpowiedzi sklepu nic nie mówi, bo jeden zawieszony pomiar psuje cały dzień. Jeśli 99 żądań trwa 0,4 s, a jedno 30 s, średnia wynosi prawie 0,7 s, choć sklep przez 99% czasu działa świetnie. Odwrotnie też się zdarza: średnia wygląda dobrze, a co dwudziesty klient czeka 5 s.

Dlatego patrz na dwie liczby:

• mediana - jak sklep działa na co dzień,
• 95. percentyl (p95) - jak działa w najgorszych 5% chwil. To te chwile klient zapamiętuje i w nich porzuca koszyk.

W IThandy Monitor z każdego żądania zapisuję czasy: DNS, połączenie, TLS, TTFB, całość i rozmiar odpowiedzi. W panelu pokazuję medianę i p95 osobno dla strony głównej, kategorii, produktu i zamówienia. Zamówienie zawsze omija cache, więc to najlepszy miernik samego serwera.

Szybki sklep w szczycie ruchu

Sklep, który jest szybki we wtorek o 10:00, może być wolny w Black Friday o 20:00, bo szczyt ruchu wyciąga na wierzch limity hostingu. Na hostingu współdzielonym masz limity procesów PHP, pamięci i operacji dyskowych. Gdy ruch rośnie, żądania czekają w kolejce, TTFB rośnie, a w końcu pojawiają się błędy 503 lub 508.

Najszybciej rośnie czas stron bez cache, czyli dokładnie koszyka i zamówienia. Dlatego przed sezonem patrz na p95 zamówienia z ostatnich tygodni, a w trakcie szczytu na alarmy o przekroczeniu progu. Pełną listę przygotowań znajdziesz w artykule monitoring sklepu na Black Friday i Black Week.

Checklista: co mierzyć i co naprawić najpierw

Zacznij od pomiaru stron bez cache, bo to tam klient traci cierpliwość i tam serwer pokazuje prawdę.

Pomiar

• TTFB strony głównej z cache i z pominięciem cache (origin).
• TTFB karty produktu, koszyka i strony zamówienia, mediana i p95.
• Czas kroków zamówienia: zmiana dostawy, płatności, kodu rabatowego.
• Core Web Vitals (LCP, INP, CLS) dla strony głównej i karty produktu na telefonie, z danych prawdziwych użytkowników (Chrome UX Report) tam, gdzie są dostępne.
• Porównanie dnia zwykłego z dniem promocji (newsletter, kampania).

Progi orientacyjne

• LCP do 2,5 s, INP do 200 ms, CLS do 0,1 (75% odsłon).
• TTFB do 0,8 s jako punkt odniesienia, a dla koszyka i zamówienia własny wzorzec z dobrego tygodnia i alarm przy wyraźnym wzroście p95.

Co naprawić najpierw

• PrestaShop: OPcache na FPM, Smarty "Nigdy nie kompiluj", przegląd modułów w hookach koszyka, CCC po teście motywu.
• WooCommerce: autoload opcji, wtyczki ładujące skrypty w checkoutcie, wykluczenia cache, kolejka Action Scheduler.
• Magento: indeksery i cron, wykluczenia Varnish, rozszerzenia checkoutu wołające zewnętrzne API.
• Wszędzie: zdjęcia w WebP lub AVIF w rozmiarze ekranu, mniej skryptów marketingowych, mapa paczkomatów ładowana dopiero po wyborze dostawy.

Jak IThandy Monitor mierzy szybkość sklepu

IThandy Monitor mierzy czas odpowiedzi tak, jak doświadcza go klient, osobno dla stron z cache i bez cache, i alarmuje, gdy sklep zwalnia lub przestaje działać. Konkretnie:

• Start (49 zł netto miesięcznie): dostępność i czas odpowiedzi strony głównej co minutę oraz pomiar serwera z pominięciem cache.
• Sklep (149 zł netto): do tego karta produktu i dodanie do koszyka co 5 minut, za każdym razem inny produkt.
• Sklep Pro (349 zł netto): do tego test zamówienia co godzinę z czasami kroków dostawy i płatności, bez składania zamówienia.

Rocznie płacisz 10 x cena miesięczna, alarmy przychodzą e-mailem. Szczegóły w cenniku.

Uczciwie o ograniczeniu: pomiar HTTP mówi, ile trwa dostarczenie HTML, a nie, ile trwa narysowanie strony w przeglądarce. Dlatego uzupełniam go o dane Core Web Vitals z PageSpeed Insights. Jeśli chcesz zobaczyć medianę i p95 swojego koszyka, zanim zaczniesz przyspieszać, sprawdź sklep 14 dni za darmo.

Powiązane: WooCommerce checkout nie działa.

Źródła

1. Deloitte i Google, "Milliseconds make millions" - studium przypadku na web.dev
2. Portent, "Site Speed is (Still) Impacting Your Conversion Rate" (2022)
3. web.dev, Web Vitals - progi LCP, INP, CLS
4. web.dev, Time to First Byte (TTFB)
5. Przelewy24, omówienie raportu Gemius "E-commerce w Polsce 2025"
6. Adobe, 2025 Holiday Shopping Recap (PDF)