Przyspieszenie WooCommerce — optymalizacja i Core Web Vitals krok po kroku

Dlaczego WooCommerce bywa wolny

WooCommerce to sklep zbudowany na WordPressie — a WordPress daje ogromną elastyczność kosztem narzutu. Front, motyw, wtyczki i baza działają na jednym serwerze, a dodatkowo sklep ma jedną cechę, która odróżnia go od zwykłej strony: koszyk i checkout są dynamiczne i nie da się ich cache'ować tak jak reszty.

Najczęstsze przyczyny wolnego WooCommerce:

• Wolny TTFB na współdzielonym hostingu — wg danych CrUX tylko część sklepów WordPress ma dobry czas odpowiedzi serwera; to główny hamulec LCP
• Nadmiar wtyczek — każda wtyczka potrafi wstrzykiwać własny CSS i JS na każdą podstronę, nawet tam, gdzie nie jest używana
• Ciężki motyw — rozbudowane motywy „multi-purpose" z page builderami dokładają dziesiątki żądań i skryptów
• Brak cache stron i obiektów — bez page cache i Redisa każde wejście generuje zapytania do bazy od zera
• Nieoptymalne obrazy i render-blocking JS — produkty w JPG/PNG, brak preloadu obrazu LCP, marketingowe skrypty ładowane od razu

Core Web Vitals w WooCommerce — co mierzyć

Core Web Vitals to metryki, którymi Google ocenia realne doświadczenie użytkownika i które wpływają na pozycje w wyszukiwarce. Cele dla sklepu WooCommerce:

Krok 1: cache stron i obiektów

Cache to najtańszy i najskuteczniejszy sposób na przyspieszenie WooCommerce. Klucz to jednak poprawne wykluczenia — koszyk, checkout i konto klienta muszą pozostać dynamiczne:

Dobra wtyczka cache (np. WP Rocket) domyślnie wyklucza koszyk i checkout — ale zawsze sprawdź, czy po włączeniu cache dodanie do koszyka i finalizacja zamówienia działają poprawnie.

Krok 2: lekki motyw i audyt wtyczek

Motyw i wtyczki to najczęstsza ukryta przyczyna wolnego WooCommerce. Zasada: każda nieużywana wtyczka to czysta strata — dokłada skrypty, style i zapytania na każdej podstronie.

Uważaj zwłaszcza na rozbudowane motywy z page builderami i wtyczki „all-in-one" ładujące własne biblioteki (slidery, popupy), które dublują to, co masz w motywie.

Krok 3: obrazy — największy dług wagi strony

Obrazy to zwykle 60–80% wagi strony i główny czynnik LCP oraz CLS. Cztery działania:

• WebP lub AVIF — nowoczesne formaty tną wagę o 30%+ przy tej samej jakości; obrazy nad pierwszym ekranem trzymaj poniżej ~100 KB
• NIE lazy-loaduj obrazu LCP — główny obraz produktu powinien być preloadowany z fetchpriority="high", a nie odkładany na później
• Lazy loading poniżej pierwszego ekranu — reszta obrazów ładuje się dopiero przy scrollu
• Sztywne wymiary — width i height na każdym obrazie i banerze; to jedyny skuteczny sposób na CLS

Krok 4: JavaScript i skrypty firm trzecich

Marketing, chaty, heatmapy i piksele społecznościowe potrafią mocno obciążać wątek główny i psuć INP. Dwie zasady:

• Defer dla niekrytycznego JS — skrypty, które nie są potrzebne do pierwszego renderu, ładuj z defer
• Delay do interakcji — skrypty marketingowe (piksele, chat, analityka zachowań) ładuj dopiero po pierwszej interakcji użytkownika, jeśli biznesowo się to spina

Krok 5: hosting, PHP i CDN

To zmiany, które najmocniej ruszają TTFB — a żadna nie wymaga przepisywania sklepu:

• Hosting zarządzany z cache serwerowym — dedykowany pod WordPress/WooCommerce, z page cache i object cache na poziomie serwera
• Object cache Redis lub Memcached — trzyma wyniki zapytań w pamięci; ogromna różnica przy katalogu i koszyku
• PHP 8.1 lub nowsze + OPcache — sam skok wersji PHP daje kilkadziesiąt procent szybszego przetwarzania
• CDN przed domeną — np. Cloudflare na statyczne zasoby; niższa latencja i odciążony serwer bez zmian w kodzie

Co daje najwięcej — kolejność działań

Jeśli masz zrobić tylko kilka rzeczy, zrób je w tej kolejności — od największego zwrotu przy najmniejszym wysiłku:

Gdzie kończy się optymalizacja motywu

Powyższe kroki potrafią przenieść sklep z wyniku 40 na 80+ w PageSpeed. Ale w pewnym momencie uderzasz w sufit architektury: front WooCommerce renderuje WordPress razem z motywem i wtyczkami na tym samym serwerze co backend. Wyczyściłeś cache, wyciąłeś wtyczki, skonwertowałeś obrazy — a narzut WordPressa i tak zostaje.

Wtedy zostaje zmiana architektury — headless. Front działa jako osobna, zoptymalizowana aplikacja na własnej infrastrukturze i komunikuje się z WooCommerce wyłącznie przez API. Panel, produkty, zamówienia i checkout zostają bez zmian — zmienia się tylko warstwa, która decyduje o wydajności.

Headless ma sens, gdy wydajność jest priorytetem, a optymalizacja motywu przestała wystarczać. Jak to działa krok po kroku, opisaliśmy w osobnych materiałach: