Jak przyspieszyć sklep WooCommerce? Poradnik krok po kroku na 2026 rok

Żeby przyspieszyć sklep WooCommerce, najpierw zmierz realne dane użytkowników (raport Core Web Vitals w Google Search Console), a dopiero potem poprawiaj kolejno: serwer i wersję PHP, cache stron i obiektów, obrazy produktów, wtyczki i JavaScript, bazę danych oraz skrypty marketingowe. Celem są trzy progi Google mierzone na 75. percentylu wizyt: LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Najwięcej zyskujesz zwykle na szablonach, które generują sprzedaż: karcie produktu, kategorii, koszyku i kasie. Poniżej pokazuję, jak przejść przez te kroki w odpowiedniej kolejności i jak sprawdzić, czy każda zmiana faktycznie pomogła.

W skrócie

• Mierz dane terenowe (Search Console, CrUX), a PageSpeed Insights traktuj jako narzędzie do diagnozy, nie jako cel.
• Optymalizuj szablony, a nie pojedyncze adresy: kategoria, produkt, koszyk i kasa mają osobne problemy.
• Koszyk, kasa i „Moje konto” nie mogą trafiać do cache stron.
• Największy element na ekranie (zwykle zdjęcie produktu) nie powinien mieć lazy loadingu.
• Od WooCommerce 8.2 nowe sklepy domyślnie przechowują zamówienia w tabelach HPOS. Starsze sklepy mogą przełączyć się ręcznie.

Spis treści

1. Dlaczego szybkość sklepu WooCommerce ma znaczenie?
2. Jak zmierzyć szybkość sklepu, żeby nie optymalizować na ślepo?
3. Które strony sklepu sprawdzać w pierwszej kolejności?
4. Krok 1: Serwer, PHP i czas odpowiedzi
5. Krok 2: Cache stron, obiektów i CDN
6. Krok 3: Zdjęcia produktów i element LCP
7. Krok 4: Wtyczki, motyw i JavaScript
8. Krok 5: Baza danych i zadania w tle
9. Krok 6: Skrypty marketingowe i baner zgód
10. Najczęstsze objawy i ich przyczyny
11. Plan przyspieszenia sklepu na 30 dni
12. Wydajność w projektach Netexo i koszt pomocy
13. Checklista: szybki sklep WooCommerce
14. FAQ

Dlaczego szybkość sklepu WooCommerce ma znaczenie?

Szybkość sklepu wpływa jednocześnie na trzy obszary, z których żyje e-commerce: widoczność w Google, koszt reklam i to, czy klient dotrze do końca zakupu.

• SEO. Core Web Vitals są częścią sygnałów, które Google opisuje w dokumentacji o doświadczeniu na stronie. Nie zastąpią dobrych treści i struktury kategorii, ale przy podobnych wynikach wolny sklep ma gorszy punkt wyjścia.
• Google Ads. Jakość strony docelowej to jeden z trzech składników Wyniku Jakości słowa kluczowego. Strona, która ładuje się długo na telefonie, utrudnia klientowi zrobienie tego, po co kliknął reklamę.
• Sprzedaż. Każde opóźnienie na karcie produktu, w koszyku czy w kasie to moment, w którym klient może zrezygnować. Problem z responsywnością (INP) czuć szczególnie przy wyborze wariantu, filtrowaniu i dodawaniu do koszyka.

Szybkość to więc nie „ładny wynik w teście”, tylko warunek, żeby ruch z SEO i reklam zamieniał się w zamówienia. Szerszy kontekst SEO sklepu opisuję w poradniku jak wypozycjonować sklep internetowy.

Jak zmierzyć szybkość sklepu, żeby nie optymalizować na ślepo?

Najczęstszy błąd to optymalizacja pod jeden wynik w PageSpeed Insights. Test laboratoryjny pokazuje, co dzieje się w symulowanych warunkach przy jednym wczytaniu. Google ocenia natomiast dane terenowe: to, czego doświadczają prawdziwi klienci na swoich telefonach i łączach.

Progi Core Web Vitals według web.dev wyglądają tak:

Wskaźnik	Co mierzy	Dobry	Wymaga poprawy	Słaby
LCP (Largest Contentful Paint)	Czas pojawienia się największego elementu, np. zdjęcia produktu	do 2,5 s	2,5–4 s	powyżej 4 s
INP (Interaction to Next Paint)	Reakcję strony na kliknięcia i dotknięcia	do 200 ms	200–500 ms	powyżej 500 ms
CLS (Cumulative Layout Shift)	Przesunięcia układu podczas ładowania	do 0,1	0,1–0,25	powyżej 0,25

Strona jest oceniana jako dobra, gdy co najmniej 75% wizyt mieści się w progu „dobry”, osobno dla telefonów i komputerów. INP zastąpił wcześniejszy wskaźnik FID w marcu 2024 roku.

Jakich narzędzi używać:

Narzędzie	Typ danych	Do czego służy w sklepie
Google Search Console, raport Core Web Vitals	Terenowe (CrUX), grupy podobnych adresów	Sprawdzenie, które szablony mają problem i czy poprawka zadziałała
PageSpeed Insights	Terenowe (jeśli są) + laboratoryjne	Diagnoza konkretnego adresu: element LCP, blokujące skrypty
Chrome DevTools, panel Performance	Laboratoryjne, na Twoim urządzeniu	Szukanie długich zadań JavaScript, które psują INP
Query Monitor (wtyczka)	Po stronie serwera	Wolne zapytania do bazy, ciężkie wtyczki, hooki
Logi serwera i panel hostingu	Po stronie serwera	Obciążenie CPU, błędy PHP, limity procesów

Ważne: dane terenowe w Search Console są zbierane z okresu 28 dni. Efekt zmiany zobaczysz więc z opóźnieniem. Dlatego przed każdą większą zmianą zapisz wynik bazowy i datę wdrożenia.

Które strony sklepu sprawdzać w pierwszej kolejności?

WooCommerce generuje kilka typów stron, a każdy z nich ma inne wąskie gardło. Zamiast poprawiać sklep „ogólnie”, sprawdź po jednym reprezentatywnym adresie z każdego szablonu.

Szablon	Typowy element LCP	Najczęstszy problem
Strona główna	Baner lub slider	Kilka dużych grafik w sliderze, skrypty karuzeli
Kategoria	Pierwsze miniatury produktów lub nagłówek	Filtry wykonujące ciężkie zapytania, zbyt wiele produktów na stronie
Karta produktu	Główne zdjęcie produktu	Lazy loading na głównym zdjęciu, ciężka galeria, skrypty wariantów
Koszyk	Tabela produktów	Brak cache (to poprawne), więc liczy się szybkość serwera i PHP
Kasa (checkout)	Formularz	Skrypty płatności i dostaw, walidacja, zewnętrzne widżety
Wyszukiwarka	Lista wyników	Wolne wyszukiwanie w bazie przy dużym katalogu

Kategorie i karty produktów przynoszą zwykle najwięcej ruchu z SEO i reklam produktowych, a koszyk i kasa decydują o sprzedaży. Od tych szablonów zacznij.

Krok 1: Serwer, PHP i czas odpowiedzi

Koszyka, kasy ani panelu klienta nie da się trzymać w cache stron, bo ich treść jest inna dla każdego klienta. Na tych stronach o szybkości decyduje serwer. Dlatego zaczynam od podstaw:

• TTFB (czas do pierwszego bajtu). Według web.dev dobry TTFB to do 0,8 s. Jeśli na koszyku lub kasie jest dużo wyższy, problem leży po stronie serwera, PHP albo bazy danych, a nie grafik.
• Wspierana wersja PHP. Sprawdź na php.net, które wersje mają jeszcze wsparcie, i upewnij się, że motyw oraz wtyczki są z nią zgodne. Zmianę testuj najpierw na kopii sklepu.
• OPcache i limity procesów. Na hostingu współdzielonym sklep potrafi zwalniać w godzinach szczytu, bo kończą się procesy PHP. Panel hostingu lub support powie Ci, czy to się zdarza.
• Lokalizacja serwera. Jeśli sprzedajesz głównie w Polsce, np. klientom z Warszawy i okolic, serwer lub CDN z węzłem w Polsce albo w pobliżu skraca drogę danych.
• HTTP/2 lub HTTP/3 i kompresja. To dziś standard, ale warto potwierdzić w nagłówkach odpowiedzi.

Jeśli sklep jest na najtańszym pakiecie i ma kilkaset produktów z wariantami, często bardziej opłaca się przenieść go na mocniejszy serwer niż dokładać kolejne wtyczki optymalizacyjne. Jeśli planujesz przy okazji zmianę hostingu lub platformy, skorzystaj z poradnika migracja sklepu internetowego.

Krok 2: Cache stron, obiektów i CDN

Cache to najtańszy sposób na szybsze strony katalogowe. W sklepie działa jednak tylko wtedy, gdy jest dobrze skonfigurowany.

Cache stron zapisuje gotowy HTML strony głównej, kategorii i kart produktów. Warunek: z cache wyłączasz strony, które muszą być spersonalizowane:

• koszyk, kasę i „Moje konto”,
• adresy z parametrami dodania do koszyka,
• sesje zalogowanych klientów (jeśli pokazujesz im indywidualne ceny, np. w B2B).

Cache obiektów (np. Redis) przechowuje wyniki zapytań do bazy w pamięci. Pomaga szczególnie tam, gdzie cache stron nie działa: w koszyku, kasie i panelu administracyjnym. Wymaga wsparcia hostingu.

CDN serwuje pliki statyczne (obrazy, CSS, JS) z serwera bliżej klienta. Przy sklepie sprzedającym tylko w Polsce zysk bywa mniejszy niż przy sprzedaży zagranicznej, ale CDN zdejmuje też obciążenie z głównego serwera.

Warstwa cache	Co przyspiesza	Na co uważać
Cache stron	Stronę główną, kategorie, produkty	Wykluczenia: koszyk, kasa, konto; czyszczenie po zmianie ceny i stanu
Cache obiektów	Zapytania do bazy, panel, koszyk	Wsparcie serwera, poprawne czyszczenie po aktualizacjach
Cache przeglądarki	Powtórne wizyty	Wersjonowanie plików po zmianach w motywie
CDN	Pliki statyczne, odciążenie serwera	Konfiguracja zgodna z cache stron i z SSL

Po włączeniu cache zrób testowe zamówienie i sprawdź, czy koszyk pokazuje właściwe produkty, a ceny i stany magazynowe aktualizują się po zmianie.

Krok 3: Zdjęcia produktów i element LCP

Na karcie produktu i w kategorii elementem LCP jest zwykle zdjęcie. To dlatego obrazy dają najszybsze efekty.

1. Format. WordPress obsługuje WebP od wersji 5.8 i AVIF od wersji 6.5 (jeśli serwer ma odpowiednią bibliotekę graficzną). Nowoczesne formaty są zwykle wyraźnie lżejsze niż JPEG przy podobnej jakości.
2. Wymiary. Nie wgrywaj zdjęć 4000 px, jeśli karta produktu wyświetla 800 px. Ustaw rozmiary miniatur WooCommerce zgodnie z motywem.
3. Bez lazy loadingu dla głównego zdjęcia. Lazy loading jest dobry dla obrazów poniżej pierwszego ekranu. Na głównym zdjęciu produktu opóźnia LCP. Takiemu obrazowi warto nadać atrybut fetchpriority="high".
4. Wymiary w kodzie. Atrybuty width i height (albo aspect-ratio w CSS) rezerwują miejsce na obraz i ograniczają CLS.
5. Galeria i slidery. Ładuj tylko pierwsze zdjęcie od razu, kolejne po interakcji. Slider na stronie głównej z pięcioma pełnoekranowymi grafikami to częsta przyczyna słabego LCP.

Zasada praktyczna: w PageSpeed Insights sprawdź, który element jest wskazany jako LCP. Jeśli to zdjęcie, zacznij od niego, a dopiero potem zajmuj się resztą.

Krok 4: Wtyczki, motyw i JavaScript

Sklep WooCommerce rzadko spowalnia jedna rzecz. Zwykle to suma: rozbudowany motyw lub page builder, kilkanaście wtyczek dodających własne skrypty na każdej stronie i widżety firm zewnętrznych.

Jak to uporządkować:

• Audyt wtyczek. Dla każdej wtyczki odpowiedz: czy jest potrzebna, na których stronach działa i czy ładuje skrypty globalnie. Query Monitor pokaże, które wtyczki generują najwięcej zapytań i czasu.
• Skrypty tylko tam, gdzie są potrzebne. Formularz kontaktowy nie musi ładować skryptów na karcie produktu, a slider nie musi działać w kasie.
• Cart fragments. Od WooCommerce 7.8 skrypt wc-cart-fragments ładuje się tylko wtedy, gdy na stronie jest widżet mini-koszyka lub gdy motyw albo wtyczka go wymusza. Jeśli Twój motyw wciąż go dołącza na każdej stronie, każde wejście generuje dodatkowe zapytanie AJAX. WooCommerce opisuje to w artykule o dobrych praktykach dla cart fragments i rekomenduje blok Mini-Cart.
• Długie zadania JavaScript. Psują INP: klient klika „Dodaj do koszyka” albo wybiera rozmiar, a strona reaguje z opóźnieniem. Szukaj ich w panelu Performance w Chrome.
• Motyw. Jeśli motyw ładuje kilka bibliotek, z których używasz jednej funkcji, czasem lepiej przebudować kluczowe szablony niż walczyć z optymalizacją.

Ostrożnie z wtyczkami, które „łączą i opóźniają cały JavaScript”. Potrafią poprawić wynik testu, ale też zepsuć warianty produktów, płatności albo zdarzenia analityczne. Każdą taką zmianę sprawdzaj testowym zamówieniem.

Krok 5: Baza danych i zadania w tle

Im dłużej działa sklep, tym więcej danych gromadzi baza: zamówienia, rewizje, sesje, tymczasowe opcje i logi wtyczek.

• HPOS (High-Performance Order Storage). Od WooCommerce 8.2 nowe instalacje domyślnie zapisują zamówienia we własnych tabelach zamiast w tabelach wpisów WordPressa. Starsze sklepy muszą się przełączyć ręcznie: najpierw synchronizacja w trybie zgodności, potem zmiana. Instrukcję znajdziesz w dokumentacji WooCommerce o HPOS. Przed przełączeniem sprawdź zgodność wtyczek i zrób kopię zapasową.
• Opcje ładowane automatycznie (autoload). Po usuniętych wtyczkach często zostają dane ładowane przy każdym wejściu na stronę. Warto je przejrzeć z kimś, kto zna strukturę WordPressa.
• Zadania zaplanowane. WooCommerce korzysta z kolejki Action Scheduler. Tysiące zaległych lub błędnych zadań (WooCommerce → Status → Zaplanowane działania) to sygnał, że coś nie działa poprawnie.
• WP-Cron. Przy większym ruchu lepiej uruchamiać zadania przez systemowy cron serwera niż przy wejściach klientów.
• Wyszukiwarka i filtry. Przy dużym katalogu filtrowanie po wielu atrybutach może generować bardzo ciężkie zapytania. Pomaga indeksowanie danych przez dedykowaną wtyczkę filtrów lub zewnętrzną wyszukiwarkę.

Filtry mają też drugą stronę: SEO. Które kombinacje filtrów indeksować, a które nie, opisuję w kroku o architekturze kategorii w poradniku jak wypozycjonować sklep internetowy.

Krok 6: Skrypty marketingowe i baner zgód

Piksele reklamowe, Google Tag Manager, czaty, widżety opinii i mapy cieplne potrafią ważyć więcej niż sam sklep. Nie chodzi o to, żeby je usunąć, bo bez pomiaru nie da się prowadzić kampanii. Chodzi o porządek:

• usuń tagi po zakończonych testach i narzędziach, z których nikt nie korzysta,
• ładuj czat i widżety po interakcji lub z opóźnieniem, a nie na starcie strony,
• sprawdź, czy baner zgód nie przesuwa układu strony (CLS),
• rozważ przeniesienie części zdarzeń na serwer, np. przez Conversions API.

Więcej o pomiarze zdarzeń z serwera piszę w poradniku Conversions API Meta w sklepie internetowym. Pamiętaj, że wysyłka z serwera nie zwalnia z obowiązku uzyskania zgody.

Najczęstsze objawy i ich przyczyny

Objaw	Najczęstsza przyczyna	Co zrobić
Wolny koszyk i kasa, reszta sklepu w porządku	Słaby serwer, stara wersja PHP, brak cache obiektów	Sprawdź TTFB, PHP i limity hostingu, rozważ Redis
Słaby LCP na kartach produktów	Ciężkie zdjęcie, lazy loading na głównym obrazie	WebP lub AVIF, właściwe wymiary, fetchpriority="high"
Słaby INP przy wyborze wariantu	Długie zadania JavaScript, ciężkie skrypty motywu	Panel Performance w Chrome, ograniczenie skryptów
Wysoki CLS	Brak wymiarów obrazów, baner zgód, doładowywane czcionki	Wymiary w kodzie, rezerwacja miejsca na banery
Sklep zwalnia w godzinach szczytu	Limity procesów PHP, zadania w tle uruchamiane przez ruch	Systemowy cron, mocniejszy serwer
Panel admina działa wolno	Duża baza zamówień, ciężkie wtyczki	HPOS, przegląd wtyczek, cache obiektów
Dobry wynik w teście, słabe dane w Search Console	Optymalizacja tylko pod komputer lub jeden adres	Mierz telefony i wszystkie kluczowe szablony

Plan przyspieszenia sklepu na 30 dni

Tydzień	Zadania	Efekt do sprawdzenia
1	Pomiar bazowy: Search Console, PageSpeed dla każdego szablonu, TTFB koszyka i kasy, lista wtyczek	Lista problemów według szablonów
2	Serwer i cache: PHP, cache stron z wykluczeniami, cache obiektów, CDN	Niższy TTFB, szybsze strony katalogowe
3	Obrazy i element LCP, porządek we wtyczkach i skryptach	Lepszy LCP i INP w testach laboratoryjnych
4	Baza danych, zadania w tle, tagi marketingowe; testowe zamówienia	Stabilny sklep, poprawne zdarzenia analityczne
Kolejne 4 tygodnie	Monitoring danych terenowych w Search Console	Potwierdzenie poprawy na prawdziwych użytkownikach

Każdą zmianę wdrażaj najpierw na kopii sklepu (stagingu), zrób kopię zapasową i zapisz datę wdrożenia. Dzięki temu wiesz, która poprawka zadziałała, a którą trzeba cofnąć.

Wydajność w projektach Netexo i koszt pomocy

W projekcie dla hurtowni gastronomicznej Makulino (serwis B2B na WordPressie) wdrożenie obejmowało techniczne SEO i optymalizację wydajności. Opublikowany rezultat to −50% krótszy czas ładowania po wdrożeniu i optymalizacji. W sklepie WooCommerce Kona Meble automatyczna synchronizacja produktów, cen i dostępności z hurtownią działa przez API, więc duży katalog nie wymaga ręcznej pracy w panelu. Więcej projektów znajdziesz w realizacjach sklepów internetowych Netexo.

Szybkość jest częścią prac technicznych przy pozycjonowaniu WooCommerce i SEO technicznym. Jeśli chcesz najpierw wiedzieć, co spowalnia sklep, zacznij od audytu sklepu internetowego.

Według cennika Netexo (ceny brutto):

• SEO od 1 490 zł/mies.,
• opieka techniczna WordPress (aktualizacje, kopie, bezpieczeństwo i drobne zmiany) od 390 zł/mies.,
• sklepy WooCommerce od 2 999 zł, jeśli obecny sklep trzeba zbudować od nowa. Zobacz też tworzenie sklepów internetowych WooCommerce.

Checklista: szybki sklep WooCommerce

• Zapisany wynik bazowy z Search Console i PageSpeed dla każdego szablonu
• TTFB koszyka i kasy sprawdzony (cel: do 0,8 s)
• Wspierana wersja PHP, zgodna z motywem i wtyczkami
• Cache stron z wykluczeniem koszyka, kasy i „Moje konto”
• Cache obiektów (np. Redis), jeśli hosting go wspiera
• Zdjęcia w WebP lub AVIF, w rozmiarach dopasowanych do motywu
• Główne zdjęcie produktu bez lazy loadingu, z fetchpriority="high"
• Wymiary obrazów i banerów zarezerwowane w kodzie (CLS)
• Przegląd wtyczek: zbędne usunięte, skrypty tylko na potrzebnych stronach
• Cart fragments ładowane tylko tam, gdzie są potrzebne
• HPOS włączone (po teście zgodności wtyczek)
• Zadania w tle bez zaległości, WP-Cron zastąpiony systemowym cronem
• Tagi marketingowe uporządkowane, czat i widżety ładowane z opóźnieniem
• Testowe zamówienie po każdej zmianie
• Monitoring danych terenowych przez 28 dni po wdrożeniu

FAQ

Jaki wynik PageSpeed Insights powinien mieć sklep WooCommerce?

Wynik w skali 0–100 to ocena laboratoryjna i nie jest celem sam w sobie. Ważniejsze są dane terenowe: LCP do 2,5 s, INP do 200 ms i CLS do 0,1 dla co najmniej 75% wizyt. Sklep z wynikiem laboratoryjnym poniżej 90 może mieć dobre dane terenowe i odwrotnie.

Która wtyczka najbardziej przyspieszy WooCommerce?

Nie ma jednej wtyczki, która rozwiąże problem. Wtyczka cache pomaga na stronach katalogowych, ale nie przyspieszy koszyka i kasy na słabym serwerze. Zacznij od pomiaru i znalezienia przyczyny, a dopiero potem dobierz narzędzie.

Czy szybkość sklepu wpływa na pozycje w Google?

Core Web Vitals są częścią sygnałów doświadczenia na stronie, które Google uwzględnia. Nie są jednak ważniejsze od trafności treści. W praktyce szybkość pomaga przede wszystkim w konwersji, a w SEO daje przewagę przy podobnej jakości stron.

Czy warto włączyć HPOS w starszym sklepie?

Zwykle tak, bo dedykowane tabele zamówień są zaprojektowane pod zapytania sklepu. Przed przełączeniem sprawdź, czy wszystkie wtyczki są zgodne z HPOS (WooCommerce pokazuje to w ustawieniach), zrób kopię zapasową i przejdź przez tryb zgodności.

Ile trwa przyspieszenie sklepu WooCommerce?

Podstawowe poprawki, takie jak cache, obrazy i porządek we wtyczkach, zajmują zwykle od kilku dni do kilku tygodni, zależnie od wielkości sklepu. Potwierdzenie w danych terenowych Search Console wymaga kolejnych około 28 dni, bo tyle obejmuje okres zbierania danych.

Chcesz sprawdzić, co spowalnia Twój sklep?

Zacznij od jednego kroku: otwórz raport Core Web Vitals w Search Console i zobacz, które grupy adresów mają status „Słaby” na telefonach. Jeśli nie wiesz, od czego zacząć poprawki, skontaktuj się z Netexo. Pracujemy z Warszawy dla sklepów z całej Polski. Wskażemy, które zmiany dadzą największy efekt przy Twoim budżecie.

Tematy

Core Web Vitals HPOS optymalizacja WooCommerce SEO techniczne szybkość sklepu WooCommerce