Sklep WooCommerce działa wolno: gdzie leży problem i jak go znaleźć samemu

Wolny WooCommerce to jeden z najczęstszych powodów wysokiego bounce rate w sklepach. Klient widzi, że coś jest nie tak, ale nie wie, gdzie leży problem: hosting, wtyczki, baza danych, obrazy, motyw. Zanim zlecisz komukolwiek optymalizację, warto wiedzieć, co konkretnie zwalnia Twój sklep. Ten przewodnik przeprowadza przez diagnostykę krok po kroku.

Dlaczego sklep WooCommerce działa wolno?

WooCommerce generuje więcej zapytań do bazy danych niż zwykły blog WordPress. Każda strona produktu, kategoria i koszyk to oddzielne zapytania. Do tego dochodzą wtyczki, które dokładają własne zapytania przy każdym ładowaniu strony. Efekt: sklep z 50 wtyczkami może wysyłać 80-150 zapytań SQL przy jednym odświeżeniu strony.

Główne przyczyny wolnego WooCommerce w kolejności częstości:

1. Przeciążony lub współdzielony serwer (TTFB powyżej 600 ms)
2. Niezoptymalizowane obrazy produktowe (brak WebP, brak lazy load)
3. Zbyt wiele wtyczek, w tym ciężkie page buildery
4. Brak pamięci podręcznej (cache) lub błędna konfiguracja
5. Niezindeksowane tabele w bazie danych
6. Ciężki motyw z dużą liczbą zewnętrznych skryptów

Większość właścicieli sklepów od razu zmienia hosting albo zleca optymalizację deweloperowi. W połowie przypadków wystarczy najpierw sprawdzić TTFB i przejrzeć bazę danych.

Krok 1: PageSpeed Insights jako punkt startowy

Wejdź na PageSpeed Insights i sprawdź trzy adresy: stronę główną, wybraną stronę produktu i stronę kategorii. Sklep może wyglądać różnie na każdej z nich.

Patrz na dwa wskaźniki w pierwszej kolejności:

• LCP (Largest Contentful Paint): cel poniżej 2,5 s. Przy WooCommerce problem najczęściej leży w głównym zdjęciu produktu lub banerze hero.
• TTFB (Time to First Byte): Google pokazuje go jako "Server response time". Cel poniżej 600 ms. Wartość powyżej 1 s prawie zawsze wskazuje na problem po stronie serwera lub bazy danych.

PageSpeed pokaże też listę "Możliwości" i "Diagnostyki". Szukaj konkretnie: "Reduce unused JavaScript", "Serve images in next-gen formats", "Eliminate render-blocking resources". Każdy z tych elementów ma szacowany zysk czasowy w sekundach.

Krok 2: TTFB mówi, gdzie szukać

TTFB to czas od wysłania żądania do otrzymania pierwszego bajtu odpowiedzi. To najprostszy test, który dzieli problem na dwa obszary:

TTFB	Diagnoza	Gdzie szukać
Powyżej 1 000 ms	Problem infrastrukturalny lub baza danych	Hosting, zapytania SQL
600-1 000 ms	Pogranicze, sprawdź obie strony	Cache, wtyczki, zapytania
Poniżej 600 ms	Serwer w normie	Obrazy, JS, CSS, motyw

Żeby zmierzyć TTFB bez narzędzi, wejdź w Chrome DevTools (F12), zakładka Network, odśwież stronę i kliknij pierwszy zasób (zwykle document). W zakładce Timing znajdziesz "Waiting for server response" czyli TTFB.

Krok 3: Query Monitor - diagnostyka zapytań bez dewelopera

Query Monitor to darmowa wtyczka WordPress (dostępna w repozytorium). Po instalacji pojawia się pasek administracyjny z danymi o każdej załadowanej stronie.

Co sprawdzić:

• Liczba zapytań do bazy: norma to 30-60 zapytań. Powyżej 100 zapytań to sygnał do działania.
• Czas zapytań: całkowity czas poniżej 100 ms to dobry wynik. Powyżej 500 ms szukaj "slow queries".
• Wolne zapytania (Slow Queries): Query Monitor oznacza zapytania przekraczające 0,05 s. Kliknij, żeby zobaczyć, która wtyczka lub motyw je generuje.
• Duplikaty zapytań: to samo zapytanie wykonywane kilkanaście razy to klasyczny błąd w słabo napisanej wtyczce.

Zainstaluj, sprawdź, a po diagnozie usuń wtyczkę. Nie zostawiaj jej na produkcji.

Krok 4: Identyfikacja problemowych wtyczek

Metoda binarna (bisect) do znalezienia ciężkiej wtyczki:

1. Wyłącz połowę wtyczek (te niezwiązane z płatnościami i bezpieczeństwem).
2. Zmierz czas ładowania.
3. Jeśli szybciej, problem leży w wyłączonej grupie. Jeśli tak samo, problem w drugiej połowie.
4. Powtarzaj do znalezienia winowajcy.

Najczęstsze winowajcy w WooCommerce: page buildery (Elementor, Divi) na stronach produktowych, wtyczki do sliderów produktów, źle skonfigurowane wtyczki SEO generujące sitemapę przy każdym żądaniu, wtyczki do live chat ładujące zewnętrzne skrypty.

Krok 5: Obrazy produktowe

WooCommerce generuje kilka rozmiarów każdego zdjęcia automatycznie. Jeśli obrazy nie są skompresowane przed wgraniem, sklep może ładować oryginały o rozmiarze 3-5 MB zamiast zoptymalizowanych miniatur.

Sprawdź w Network (DevTools) zakładkę Img: szukaj plików powyżej 200 KB na stronie produktu. Jeśli widzisz zdjęcia 500 KB-2 MB, to jest przyczyna wolnego LCP.

Szybka naprawa bez dewelopera: wtyczka Imagify lub ShortPixel (obie mają darmowe plany) zoptymalizuje istniejące obrazy w bibliotece medialnej i skompresuje nowe automatycznie. Dodaj konwersję do WebP: średni zysk to 25-35% mniej danych do pobrania.

Krok 6: Cache

WooCommerce ma specyficzne wymagania dotyczące cache: koszyk, strony checkout i obszar "Moje konto" nie mogą być cachowane. Błędna konfiguracja może powodować, że użytkownicy widzą koszyki innych klientów albo cache w ogóle nie działa.

Sprawdź, czy masz aktywną wtyczkę cache: WP Rocket, LiteSpeed Cache (jeśli serwer działa na LiteSpeed) lub W3 Total Cache. LiteSpeed Cache na serwerze LiteSpeed działa na poziomie serwera, nie PHP, co daje realnie szybszy czas odpowiedzi niż cache wtyczkowy.

Jeśli masz LiteSpeed Cache i serwer LiteSpeed, upewnij się, że w ustawieniach wtyczki masz włączone: "Cache Logged-in Users" wyłączone, "WooCommerce Object Cache" włączone, "Lazy Load Images" włączone.

Kiedy problem leży w hostingu, nie w kodzie

Jeśli TTFB konsekwentnie przekracza 800 ms mimo włączonego cache, problem leży prawdopodobnie w infrastrukturze. Współdzielony hosting upycha tysiące sklepów na jednym serwerze. W godzinach szczytu zasoby są limitowane, a Twój sklep czeka w kolejce na procesor i pamięć.

Sygnały, że hosting jest wąskim gardłem:

• TTFB zmienia się drastycznie w zależności od pory dnia (rano szybko, w południe wolno)
• PageSpeed pokazuje "Server Response Time" jako czerwony element
• Serwer działa na Apache zamiast LiteSpeed lub nginx
• Brak izolacji zasobów (CloudLinux lub podobne)
• Dyski HDD zamiast NVMe SSD

Migracja na serwer z LiteSpeed, NVMe i izolacją zasobów (np. CloudLinux) zwykle skraca TTFB o 40-60% bez zmiany kodu. W przypadku sklepu Sedan — zbudowanego od zera na dedykowanej infrastrukturze — wynik LCP na stronie produktowej osiągnął poziom poniżej 1,8 s. To bezpośredni efekt doboru stosu, nie tylko optymalizacji kodu.

Jeśli po diagnozie okazuje się, że problem leży w infrastrukturze, sprawdź ofertę hostingu i utrzymania — stawiam na butikowe środowisko z NVMe, LiteSpeed i izolacją zasobów, odpowiedzialne za cały stos.

Kolejność działań, gdy nie wiesz, od czego zacząć

1. Zmierz TTFB (DevTools lub PageSpeed).
2. Jeśli TTFB powyżej 800 ms: sprawdź hosting i zapytania bazodanowe (Query Monitor).
3. Jeśli TTFB w normie: sprawdź obrazy (Network → Img) i wtyczki (metoda binarna).
4. Włącz lub popraw konfigurację cache.
5. Sprawdź LCP po każdej zmianie, nie rób kilku rzeczy naraz.

Większość sklepów z TTFB w normie można przyspieszyć do LCP poniżej 2,5 s bez angażowania dewelopera. Jeśli po tych krokach wynik wciąż jest poniżej oczekiwań, problem leży głębiej: w bazie danych, kodzie motywu lub infrastrukturze.