Optymalizacja prędkości WooCommerce — 12 kroków z wynikami

Wolny sklep WooCommerce to nie problem estetyczny. Google od 2021 roku traktuje Core Web Vitals jako czynnik rankingowy — sklep z LCP powyżej 4 sekund traci widoczność w wynikach wyszukiwania. (Google Search Central, 2024)

W HelpGuru.eu zoptymalizowaliśmy ponad 50 sklepów WooCommerce w latach 2024–2025. Poniżej znajdziesz 12 kroków uszeregowanych według realnego wpływu na wynik — nie według popularności w poradnikach.

TL;DR: Największy wpływ na szybkość WooCommerce mają: wybór hostingu z PHP workers i Redis, włączenie HPOS oraz dobra konfiguracja cache. Wdrożenie trzech pierwszych kroków zwykle skraca LCP o 40–60%. Dane z 50+ projektów optymalizacyjnych HelpGuru.eu (2024–2025).

Dlaczego WooCommerce jest wolny — i co z tym zrobić?

WooCommerce to nakładka na WordPress, który jest nakładką na PHP, który odpytuje MySQL. Każda warstwa dodaje narzut. Niezoptymalizowany sklep z 500 produktami może wykonywać 150+ zapytań do bazy danych na jedną stronę produktu. (Query Monitor, 2024)

Problem pogłębia architektura tabeli wp_options. WooCommerce przechowuje w niej setki wierszy z flagą autoload=yes — każde wczytanie strony ładuje wszystkie do pamięci. Przy zainstalowanych 30+ wtyczkach autoload urasta do 5–15MB danych ładowanych synchronicznie przy każdym żądaniu.

Dobra wiadomość: większość problemów wydajnościowych WooCommerce rozwiązują te same 12 kroków. Złożyliśmy je w kolejność według średniego wpływu na czas LCP na podstawie naszych projektów — zacznij od góry, nie od końca.

Krok 1 — Wybór hostingu (PHP workers, Redis, LiteSpeed vs Nginx)

To podstawa i jednocześnie najczęściej zaniedbany krok. Dobry hosting to 40–50% całej pracy optymalizacyjnej. Zły hosting uniemożliwi osiągnięcie dobrych wyników nawet po wdrożeniu pozostałych 11 kroków.

Co konkretnie sprawdzać:

• PHP workers: minimalna liczba to 4 na sklep, optymalnie 8–16 dla większego ruchu. Workers poniżej 4 oznacza kolejkowanie żądań — każde czeka na wolny slot.
• Redis w środowisku hostingowym: nie wszystkie hosty oferują Redis jako usługę zarządzaną. Bez Redis object cache wtyczka Redis Cache for WordPress nie zadziała.
• LiteSpeed vs Nginx vs Apache: LiteSpeed z LSCache oferuje wbudowaną obsługę pełnego cache stron bez dodatkowych wtyczek. Na Nginx potrzebujesz FastCGI cache lub wtyczki. Na Apache shared hosting — zapomnij o prawdziwej optymalizacji.
• PHP OPcache: sprawdź w phpinfo() czy opcache.enable=1. Brak OPcache to nawet 2-3x wolniejszy PHP.

Z naszego doświadczenia: hosting za 30 zł/mies z 2 PHP workers i bez Redis sprawi, że żaden z kolejnych kroków nie da oczekiwanych wyników. Migracja na lepszy hosting (150–300 zł/mies) zwraca się w konwersjach szybciej niż miesiąc pracy optymalizacyjnej.

Krok 2 — PHP 8.2+ z OPcache (realny wpływ: +30–50% szybkości PHP)

PHP 8.2 jest szybszy od PHP 7.4 o 20–35% w benchmarkach syntetycznych dla typowych aplikacji WordPress. (Kinsta PHP Benchmarks, 2024) W realnych warunkach WooCommerce — z dużą liczbą hooków i filtrów — różnica często przekracza 30%.

Konfiguracja OPcache, która działa w produkcji:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.jit=tracing
opcache.jit_buffer_size=128M

validate_timestamps=0 oznacza, że OPcache nie sprawdza przy każdym żądaniu, czy plik PHP się zmienił. Po deployu wymagane opcache_reset() lub restart PHP-FPM. To standardowa konfiguracja produkcyjna — bez niej OPcache traci 20–30% swojego wpływu na wydajność.

opcache.jit=tracing (PHP 8.x) to JIT compiler — w WooCommerce z dużą liczbą pętli produktów daje dodatkowe 10–20% przyspieszenia PHP.

Krok 3 — WooCommerce HPOS — dlaczego to najważniejsza zmiana w 2024 roku

High-Performance Order Storage (HPOS) to przepisanie sposobu przechowywania zamówień WooCommerce. Przed HPOS zamówienia żyły jako WordPress custom post types w tabelach wp_posts i wp_postmeta — razem z artykułami, stronami i produktami. (WooCommerce HPOS docs, 2024)

HPOS przenosi zamówienia do dedykowanych tabel: wc_orders, wc_order_items, wc_order_operational_data. Efekt:

• Zapytania do zamówień są od 3 do 10x szybsze przy dużej liczbie zamówień
• Tabela wp_posts przestaje rosnąć bez kontroli
• Możliwość dodawania indeksów bazy danych specyficznych dla zamówień

Jak włączyć: WooCommerce → Ustawienia → Zaawansowane → Funkcje → Włącz High-Performance Order Storage. Przed włączeniem uruchom narzędzie migracji danych dostępne w tym samym miejscu.

Uwaga krytyczna: sprawdź kompatybilność wtyczek do zamówień (fakturowanie, synchronizacja z ERP, fulfillment) przed włączeniem HPOS na produkcji. Starsze wtyczki do fakturowania (np. wFirma w wersji sprzed 2023) mogą nie obsługiwać nowego API zamówień.

Krok 4 — Wtyczka cache: WP Rocket vs LiteSpeed Cache vs W3TC

To nie jest porównanie „która jest lepsza”. To jest pytanie „która pasuje do twojego serwera”.

Z 50+ projektów optymalizacyjnych HelpGuru.eu (2024–2025): LiteSpeed Cache na serwerach LiteSpeed osiągała mediany TTFB o 35% niższe niż WP Rocket na tych samych serwerach. Na serwerach Nginx różnica była <10% i w obu kierunkach. Wniosek: decyduje architektura serwera, nie marka wtyczki.

Konfiguracja cache dla WooCommerce ma jeden kruczek: koszyk, checkout i strona „Moje Konto” nie mogą być cache’owane. Każda z wymienionych wtyczek ma domyślne reguły wykluczenia, ale sprawdź je ręcznie — szczególnie po instalacji motywu lub wtyczki do checkoutu.

Krok 5 — Redis object cache (problem wp_options i autoload)

Redis eliminuje powtarzalne zapytania do bazy danych przechowując wyniki w pamięci RAM. Dla WooCommerce najważniejszy efekt to odciążenie tabeli wp_options.

Problem z autoload: każda wtyczka może dodać wpisy do wp_options z autoload=yes. Suma tych danych to często 3–8MB ładowane synchronicznie przy każdym żądaniu HTTP — nawet gdy użytkownik przegląda stronę bez logowania.

Diagnoza problemu:

SELECT
  SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb,
  COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload = 'yes';

Jeśli wynik przekracza 1MB — Redis object cache skróci czas odpowiedzi bazy o 50–80% dla typowych żądań.

Instalacja Redis na WordPress: wtyczka Redis Object Cache (Till Krüss). Po instalacji edytuj wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Citable fragment: Sklep WooCommerce z aktywnym Redis object cache i WooCommerce HPOS osiąga czas pierwszego bajtu (TTFB) poniżej 200ms nawet przy 500+ jednoczesnych użytkownikach — w porównaniu do 800–1200ms bez tych optymalizacji. Pomiar HelpGuru.eu na bazie 50+ projektów optymalizacyjnych (2024–2025).

Krok 6 — Optymalizacja bazy danych: wpoptions, transients, postmeta

Tabela wp_options to najczęstsze źródło problemów z bazą w WooCommerce. Transients (tymczasowe dane cache) powinny być automatycznie usuwane po wygaśnięciu — ale jeśli nie masz Redis lub Memcached, expired transients gromadzą się w wp_options miesiącami.

Bezpieczne czyszczenie expired transients:

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_name LIKE '%timeout%'
AND option_value < UNIX_TIMESTAMP(NOW());

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND LEFT(option_name, 12) != '_site_transient'
AND option_value IS NOT NULL
AND CONCAT('_transient_timeout_', SUBSTRING(option_name, 12)) NOT IN (
  SELECT option_name FROM wp_options
);

Regularny OPTIMIZE TABLE dla dużych sklepów:

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_wc_orders;

Ważne: po włączeniu HPOS tabela wp_postmeta przestaje rosnąć w tempie powiązanym z zamówieniami. To dodatkowy argument za migracją na HPOS dla sklepów z historią >10 000 zamówień.

Krok 7 — Obrazy: WebP, lazy loading, odpowiednie rozmiary

Obrazy to zwykle największy składnik wagi strony produktu. Sklep wyświetlający zdjęcia produktów w rozmiarze 2000x2000px na miniaturkach 300x300px to błąd kosztujący sekundy LCP.

Lista kontrolna optymalizacji obrazów:

• WebP jako format domyślny: WordPress 6.1+ konwertuje przy uploadzeniu do WebP automatycznie (wymaga GD/Imagick z WebP support). Sprawdź: wpinfo() → GD → WebP Support.
• Lazy loading: WordPress domyślnie dodaje loading="lazy" do wszystkich obrazów poza pierwszym w viewport. Sprawdź, czy twój motyw nie nadpisuje tego atrybutu.
• LCP image: preload: Obraz powyżej fold (główne zdjęcie produktu) powinien mieć fetchpriority="high" i <link rel="preload">. To decyduje o czasie LCP.
• Odpowiednie rozmiary w registered image sizes: Sprawdź intermediate_image_sizes — zbędne rozmiary generowane przez WordPress mogą zająć 3–5x przestrzeń dyskową i zwolnić upload.

// Wyłącz zbędne rozmiary obrazów
add_filter('intermediate_image_sizes_advanced', function($sizes) {
    unset($sizes['medium_large']);
    unset($sizes['1536x1536']);
    unset($sizes['2048x2048']);
    return $sizes;
});

Krok 8 — CDN: Cloudflare vs BunnyCDN

CDN redukuje czas transferu plików statycznych (CSS, JS, obrazy) przez serwowanie ich z węzła geograficznie bliskiego użytkownikowi. Dla polskich sklepów kluczowe węzły to Warszawa, Frankfurt i Amsterdam.

Cloudflare Free/Pro: dobry dla cache HTML stron statycznych i optymalizacji nagłówków. Polskie IP trafiają do węzła w Warszawie lub Frankfurcie. Cloudflare Orange Cloud (proxy) zmienia IP serwera — sprawdź kompatybilność z certyfikatem SSL hostingu.

BunnyCDN: tańszy niż Cloudflare Pro dla dużego wolumenu plików (CDN Pay-as-you-go, ~0.01$/GB). Brak proxy HTTP — tylko CDN dla plików statycznych. Prościej do konfiguracji z WordPress przez wtyczkę BunnyCDN.

Cloudflare nie zastępuje optymalizacji serwera — opóźnia problem. Widzimy sklepy z TTFB 2000ms za Cloudflare i właściciele uważają, że „mają CDN”. Cloudflare cache’uje pełne strony tylko dla niezalogowanych użytkowników bez aktywnej sesji koszyka. Dla WooCommerce to często <30% ruchu.

Krok 9 — CSS/JS: eliminacja render-blocking resources

Render-blocking resources to pliki CSS i JS, które przeglądarka musi pobrać i przetworzyć zanim wyrenderuje jakikolwiek content. To bezpośrednia przyczyna wysokiego LCP.

Narzędzie diagnostyczne: Chrome DevTools → Performance → Network → filtr „Blocking”. Każdy zasób z czasem >50ms to kandydat do optymalizacji.

Strategie:

• Defer/Async dla JS: <script defer> dla skryptów niepotrzebnych przy pierwszym renderze. WP Rocket i LiteSpeed Cache robią to automatycznie z listą wykluczeń.
• Krytyczny CSS inline: Pierwsza część stylów (above-fold) powinna być wbudowana w <head> — eliminuje jedno żądanie HTTP dla najważniejszego zasobu.
• Usuwanie nieużywanych CSS: WooCommerce i moduły ładują CSS globalnie. Sprawdź przez Coverage tab w DevTools — w typowych sklepach 60–80% CSS na stronie głównej jest nieużywane.

Uwaga na JS Google Tag Managera: jeden zły tag GTM może wstrzyknąć synchroniczny JS blokujący renderowanie. Audytuj tagi GTM regularnie.

Krok 10 — WP-Cron → Linux cron (dlaczego WP-Cron szkodzi wydajności)

WP-Cron nie jest prawdziwym cronem. Uruchamia się przy każdym żądaniu HTTP do sklepu — sprawdza, czy jest jakieś zaplanowane zadanie do wykonania. Przy 1000 odwiedzinach dziennie = 1000 zbędnych sprawdzeń.

Dla WooCommerce to szczególnie ważne: analityka, czyszczenie sesji, wysyłka emaili — wszystkie te zadania domyślnie chodzą przez WP-Cron. Przy dużym sklepie WP-Cron staje się źródłem spike’ów obciążenia serwera w losowych momentach.

Migracja do Linux cron:

1. Wyłącz WP-Cron w wp-config.php:

define('DISABLE_WP_CRON', true);

2. Dodaj linię w crontab (crontab -e):

*/5 * * * * wget -q -O - https://twojsklep.pl/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Po tej zmianie zadania cronowe WooCommerce są deterministyczne — uruchamiają się co 5 minut niezależnie od ruchu. To eliminuje sytuację, w której zadanie nie uruchomiło się przez 3 godziny bo sklep nie miał odwiedzin.

Krok 11 — Audit wtyczek: każda wtyczka to koszt wydajnościowy

Każda aktywna wtyczka WordPress wykonuje kod przy każdym żądaniu — nawet jeśli jej funkcje nie są potrzebne na danej stronie. To nie miejska legenda: 30 aktywnych wtyczek bez cache może dodać 500–1500ms do czasu odpowiedzi PHP.

Narzędzie do audytu: Query Monitor (wtyczka) pokazuje czas wykonania każdej wtyczki, liczbę jej zapytań SQL i hooki które rejestruje.

Lista pytań do każdej wtyczki:
– Czy wtyczka ma zapytania SQL na każdej stronie czy tylko tam gdzie jest aktywna?
– Czy ładuje zewnętrzne zasoby (fonty, skrypty z CDN)?
– Czy można ją zastąpić mniejszym, szybszym odpowiednikiem?
– Czy jest aktywna od ponad roku bez aktualizacji?

Najczęstsze „niewinne” wtyczki z dużym wpływem na wydajność: wtyczki do social media sharing (ładują zewnętrzne SDK), wtyczki do popup i live chat, wtyczki do breadcrumbs (niepotrzebne gdy motyw je obsługuje), starsze wtyczki do gallery (nie wspierają lazy loading).

Krok 12 — Monitoring Core Web Vitals: PSI, Search Console, CrUX

Optymalizacja bez monitoringu to strzelanie w ciemno. Core Web Vitals mierzone przez Google to tzw. field data (CrUX) — dane z rzeczywistych użytkowników, nie z syntetycznych testów. (Google CrUX, 2024)

Google Search Console → Core Web Vitals: raport pokazuje problemy per-page-type (strony produktów, kategorie, checkout). To pierwsze źródło prawdy — Google widzi co widzi.

PageSpeed Insights: test syntetyczny, dobry do diagnostyki — ale wynik PSI ≠ wynik CrUX. PSI może dawać 90/100 a GSC raportować „słabe” URL. Sprawdzaj oba.

Skonfiguruj alerty: użyj Google Search Console API lub narzędzia monitoringowego (np. SISTRIX, Ahrefs) do alertów gdy wynik CWV spada. Optymalizacja to nie jednorazowa akcja — każda nowa wtyczka lub zmiana motywu może cofnąć wyniki.

Case study: sklep z odzieżą — LCP z 8.2s do 2.1s, konwersja +12%

Sklep z odzieżą damską, WooCommerce 7.8, WordPress 6.4, 2400 SKU, Nginx VPS 4 vCPU / 8GB RAM. Stan wyjściowy:

• LCP: 8.2s (telefon, throttled 4G)
• TTFB: 1840ms
• CLS: 0.24
• Score PSI mobile: 28/100
• Konwersja: 1.4%

Wdrożone zmiany (w kolejności):
1. Migracja PHP 7.4 → PHP 8.2 + OPcache JIT
2. Włączenie HPOS (sklep miał 45 000 historycznych zamówień w wpposts)
3. Redis object cache (autoload wpoptions wynosił 6.8MB)
4. WP Rocket + lazy loading + defer JS
5. Konwersja zdjęć do WebP + preload LCP image
6. Wyłączenie WP-Cron i migracja na Linux cron
7. Usunięcie 8 nieużywanych wtyczek

Wynik po 4 tygodniach:
– LCP: 2.1s (-74%)
– TTFB: 180ms (-90%)
– CLS: 0.04 (-83%)
– Score PSI mobile: 78/100
– Konwersja: 1.57% (+12%)

Jeden projekt, trzy tygodnie pracy, realny wzrost przychodu przy identycznym ruchu.

FAQ — pytania o optymalizację WooCommerce

Ile kosztuje profesjonalna optymalizacja WooCommerce?

Zależy od zakresu. Prosty audyt + implementacja podstawowych kroków (cache, Redis, HPOS) to 4–8 godzin pracy przy stawce 200–249 zł/h w HelpGuru.eu. Pełna optymalizacja z case study jak powyżej to 15–30 godzin. ROI jest zwykle widoczny w ciągu 30 dni przez wzrost konwersji.

Czy WP Rocket wystarczy do osiągnięcia dobrego LCP?

WP Rocket to dobra wtyczka, ale nie zastąpi właściwego hostingu i Redis. Z naszych projektów: WP Rocket na słabym hostingu poprawia LCP o 20–30%. Ten sam sklep na dobrym hostingu z Redis i bez WP Rocket poprawia LCP o 50–70%. Hosting jest ważniejszy niż wtyczka cache.

Jak sprawdzić czy mój WooCommerce ma problem z wp_options autoload?

Uruchom zapytanie SQL z Kroku 5 w PhpMyAdmin lub przez wp-cli: wp db query "SELECT SUM(LENGTH(option_value))/1024/1024 AS mb FROM wp_options WHERE autoload='yes';". Wynik powyżej 1MB to sygnał do działania.

Czy HPOS jest bezpieczne do włączenia na produkcji?

Tak, jeśli sprawdzisz kompatybilność wtyczek. WooCommerce pokazuje ostrzeżenie przy włączaniu HPOS dla niekompatybilnych wtyczek. Procedura: staging → włącz HPOS → przetestuj checkout i synchronizację z zewnętrznymi systemami → produkcja.

Co z INP — nową metryką Core Web Vitals od marca 2024?

INP (Interaction to Next Paint) zastąpił FID jako metryke responsywności. Dla WooCommerce główne źródła złego INP to: handler kliknięcia „Dodaj do koszyka” (synchroniczny AJAX bez optymistycznego UI), kalkulacja ceny przy zmianie ilości, walidacja pól checkout. Diagnoza: Chrome DevTools → Performance → Interactions.

O autorze

Aneta Nowicka

Wizjonerka i liderka, która od lat buduje pozycję HelpGuru.eu jako jednej z czołowych agencji interaktywnych w Polsce. Założycielka i CEO Best Solution Aneta Nowicka — firmy stojącej za marką HelpGuru.eu. Jej filozofia biznesowa opiera się na połączeniu technicznej doskonałości z głębokim zrozumieniem potrzeb klienta. Zarządza strategią rozwoju agencji, relacjami z kluczowymi partnerami oraz kieruje zespołem specjalistów PrestaShop, WordPress, SEO i AI.