- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
Google potwierdza to, co właściciele sklepów czują intuicyjnie: każda sekunda ładowania kosztuje. Badania przeprowadzone przez Google i Deloitte pokazują, że przyspieszenie strony mobilnej o 0,1 sekundy przekłada się na 8% wzrost konwersji w e-commerce. Amazon szacuje, że każde 100ms opóźnienia to 1% mniej sprzedaży. Przy sklepie generującym 500 000 PLN rocznie — to 5 000 PLN rocznie traconych na każde 100 milisekund za wolno.
WooCommerce jest szczególnie podatny na problemy z prędkością. Elastyczność platformy — możliwość dodawania dziesiątek wtyczek i motywów — jest jednocześnie jej największą słabością wydajnościową. Ten artykuł to praktyczny przewodnik: jak zdiagnozować co spowalnia Twój sklep i co naprawić w pierwszej kolejności.
Twój sklep ładuje się za wolno?
Dlaczego prędkość sklepu bezpośrednio wpływa na sprzedaż
Prędkość ładowania to nie kwestia techniczna — to kwestia biznesowa. Badanie Baymard Institute pokazuje, że 17% użytkowników porzuca koszyk właśnie z powodu „zbyt wolnej strony”. To trzecia najczęstsza przyczyna porzuconych koszyków, zaraz po ukrytych kosztach i wymogu rejestracji.
Google od 2021 roku uwzględnia Core Web Vitals jako czynnik rankingowy. Sklep, który ładuje się wolno, jest penalizowany podwójnie: traci klientów bezpośrednio przez frustrację i traci widoczność organiczną przez gorsze pozycje w wynikach wyszukiwania. W konkurencyjnych kategoriach produktowych różnica jednego miejsca w TOP10 może oznaczać kilkadziesiąt procent różnicy w ruchu.
Aspekt mobilny jest szczególnie istotny. W polskim e-commerce ponad 60% ruchu pochodzi z urządzeń mobilnych — a sieci komórkowe i słabsze procesory smartfonów wyolbrzymiają każdy problem z wydajnością. Sklep, który ładuje się 2 sekundy na laptopie, może ładować się 5 sekund na średniej klasy telefonie w sieci 4G.
Core Web Vitals — co mierzy Google i co naprawdę ma znaczenie
Core Web Vitals to trzy metryki, które Google uznaje za kluczowe dla doświadczenia użytkownika. Warto je znać, bo to właśnie one decydują o ocenie Twojego sklepu w Google Search Console i PageSpeed Insights.
LCP (Largest Contentful Paint) — czas do załadowania największego elementu widocznego na ekranie (najczęściej główne zdjęcie produktu lub baner hero). Cel: poniżej 2,5 sekundy. To najważniejsza metryka dla sklepów — użytkownik ocenia prędkość strony głównie na podstawie tego, kiedy pojawia się główna treść.
INP (Interaction to Next Paint) — czas reakcji strony na interakcję użytkownika (kliknięcie, scroll, wpisanie tekstu). Zastąpił FID od marca 2024. Cel: poniżej 200ms. W WooCommerce problemy z INP najczęściej powodują ciężkie skrypty JavaScript wtyczek i widgetów.
CLS (Cumulative Layout Shift) — miara niestabilności layoutu, czyli ile elementy strony „skaczą” podczas ładowania. Cel: poniżej 0,1. W sklepach WooCommerce najczęstsza przyczyna to obrazy bez zdefiniowanych wymiarów i dynamicznie ładowane banery reklamowe.
Nie wiesz jak wypadają Core Web Vitals Twojego sklepu? Sprawdzimy i powiemy co naprawić w pierwszej kolejności.
Diagnoza: jak sprawdzić co spowalnia Twój sklep
Zanim zaczniesz optymalizować, musisz wiedzieć co optymalizować. Ślepa optymalizacja to strata czasu i pieniędzy — sklepy często mają jeden dominujący problem, który odpowiada za 70% opóźnienia.
Google PageSpeed Insights (pagespeed.web.dev) — darmowe narzędzie Google, które analizuje stronę i podaje ocenę 0-100 osobno dla mobile i desktop. Ważne: analizuj wersję mobilną, bo to ona ma znaczenie dla SEO. Narzędzie wskazuje konkretne problemy z opisem i szacowaną oszczędnością czasu po naprawie — zacznij od tych z największą oszczędnością.
Google Search Console → Raport Core Web Vitals — pokazuje dane z rzeczywistych odwiedzin użytkowników (nie laboratoryjne), co daje bardziej miarodajny obraz. Jeśli tu masz czerwone lub żółte statusy, Google aktywnie penalizuje Twój sklep w wynikach.
WebPageTest.org — bardziej zaawansowane narzędzie dla tych, którzy chcą zobaczyć waterfall ładowania zasobów. Pozwala zidentyfikować które konkretnie zasoby (skrypty, obrazy, czcionki) blokują renderowanie strony.
Obrazy — największy winowajca w WooCommerce
W zdecydowanej większości sklepów WooCommerce, które mają problemy z prędkością, głównym winowajcą są obrazy. Zbyt duże, w złym formacie, bez kompresji, ładowane wszystkie naraz — to typowy profil wolnego sklepu.
Format WebP zamiast JPEG i PNG to pierwszy krok. WebP oferuje porównywalną jakość wizualną przy rozmiarze pliku mniejszym o 25-35%. Nowoczesne przeglądarki obsługują WebP powszechnie — możesz wdrożyć go przez element <picture> z fallbackiem do JPEG dla starszych przeglądarek, lub przez wtyczkę (Imagify, ShortPixel, EWWW) która konwertuje automatycznie przy przesyłaniu.
Lazy loading — ładowanie obrazów dopiero gdy użytkownik przewija do nich ekran — jest wbudowane w WordPress od wersji 5.5 przez atrybut loading="lazy". Upewnij się jednak, że główny obraz LCP (zazwyczaj pierwsze zdjęcie na stronie produktu lub hero na stronie głównej) ma fetchpriority="high" i nie ma lazy loading — to jeden z częstszych błędów spowalniających LCP.
Rozmiary obrazów w WooCommerce: zdjęcia produktów powinny być generowane w kilku rozmiarach (thumbnail, medium, large) i serwowane w rozmiarze odpowiednim dla urządzenia przez atrybut srcset. Wysyłanie obrazu 2000×2000px do użytkownika oglądającego miniaturkę 300×300px na telefonie to marnotrawstwo przepustowości i czasu ładowania.
Hosting i serwer — gdzie zaczyna się prędkość
Najlepsza optymalizacja frontendowa nie pomoże, jeśli serwer odpowiada wolno. TTFB (Time to First Byte) — czas od wysłania żądania do pierwszego bajtu odpowiedzi serwera — powinien wynosić poniżej 200ms. Jeśli Twój sklep ma TTFB powyżej 500ms, optymalizacja obrazów i skryptów jest drugorzędna wobec problemu serwerowego.
PHP 8.2+ zamiast starszych wersji to prosta i bezpłatna poprawa wydajności — PHP 8.x jest nawet dwukrotnie szybszy od PHP 7.4 w benchmarkach WooCommerce. Sprawdź w panelu hostingowym jaką wersję PHP obsługuje Twój sklep i zaktualizuj jeśli możliwe.
Hosting współdzielony (shared hosting) to najczęstszy problem podstawowy. Na współdzielonym serwerze Twój sklep dzieli zasoby z setkami innych stron — w godzinach szczytu możesz odczuć dramatyczny spadek wydajności. VPS lub hosting zarządzany dedykowany dla WordPress/WooCommerce (Kinsta, WP Engine, Cloudways) daje przewidywalną wydajność i zazwyczaj wbudowane cache serwerowe (Redis, Memcached).
Twój sklep ładuje się zbyt wolno i nie wiesz od czego zacząć? Zrobimy audyt techniczny i wskażemy priorytety.
Cache, CDN i optymalizacja bazy danych
Cache to mechanizm przechowywania wygenerowanych stron HTML w pamięci, żeby nie musieć generować ich od nowa przy każdym odwiedzeniu. Dla sklepu WooCommerce, gdzie strona główna i kategorie są identyczne dla wszystkich niezalogowanych użytkowników, cache może obniżyć czas ładowania o 60-80%.
Popularne wtyczki cache dla WooCommerce: WP Rocket (płatna, najlepsze wyniki), LiteSpeed Cache (bezpłatna, wymaga hostingu LiteSpeed), W3 Total Cache (bezpłatna, wymaga konfiguracji). Ważne: cache musi być inteligentnie wyłączony dla stron koszyka, checkoutu i konta klienta — te strony muszą być generowane dynamicznie. Dobre wtyczki cache robią to automatycznie.
CDN (Content Delivery Network) to sieć serwerów rozmieszczonych geograficznie, która serwuje statyczne zasoby (obrazy, CSS, JS) z serwera najbliższego użytkownikowi. Cloudflare w darmowym planie to minimum dla każdego sklepu — redukuje latencję i chroni przed atakami DDoS. Przy ruchu zagranicznym CDN jest niezbędny.
Baza danych MySQL w WooCommerce rośnie z czasem: tabele logów transakcji, sesji, wersji postów i meta danych produktów mogą liczyć miliony rekordów. Regularna optymalizacja bazy (usuwanie rewizji postów, wygasłych transient options, starych sesji) przekłada się na szybsze zapytania. Wtyczka WP-Optimize lub WP Sweep wykonuje to automatycznie według harmonogramu.
Zbędne wtyczki, skrypty i blokujący rendering
Każda wtyczka WordPressa to potencjalne obciążenie: własne skrypty JavaScript, arkusze CSS, zapytania do bazy danych przy każdym załadowaniu strony. Sklep z 40 aktywnymi wtyczkami prawie zawsze ma problem z wydajnością — nie dlatego że 40 wtyczek to zła liczba per se, ale dlatego że wiele z nich ładuje zasoby globalnie, nawet na stronach gdzie ich funkcje nie są używane.
Audyt wtyczek: zaznacz każdą wtyczkę i odpowiedz szczerze — czy aktywnie jej używasz? Czy robi coś, czego nie robi inna wtyczka? Czy jest alternatywa wbudowana w WordPress lub WooCommerce? Często można zastąpić 5 małych wtyczek jedną dobrą lub wbudowaną funkcją. Mniej kodu to szybszy sklep.
Render-blocking resources to skrypty i style, które blokują renderowanie strony — przeglądarka musi je załadować zanim wyświetli cokolwiek użytkownikowi. JavaScript powinien być ładowany z atrybutem defer lub async, a nieużywany CSS powinien być usunięty lub ładowany asynchronicznie. Google Fonts ładowane przez <link rel="stylesheet"> blokują rendering — zastąp je techniką preload+onload lub pobierz fonty lokalnie.
Kiedy optymalizacja nie wystarczy
Istnieje punkt, po którym optymalizacja istniejącego sklepu WooCommerce przestaje dawać efekty. Dzieje się tak gdy sklep ma setki tysięcy produktów i złożone filtry, gdy ruch jest bardzo wysoki i serwer nie nadąża niezależnie od cache, albo gdy architektura sklepu wymaga fundamentalnych zmian (np. przejście na headless lub zmiana platformy).
Sygnały, że czas na większe zmiany: PageSpeed nie przekracza 50 punktów mimo wdrożenia wszystkich optymalizacji, TTFB przekracza 1 sekundę nawet na dobrym hostingu, sklep regularnie „pada” w godzinach szczytu sprzedaży, a każda nowa wtyczka jest problemem wydajnościowym. W takich przypadkach warto rozważyć migrację na szybszą platformę, architekturę headless lub dedykowany system sklepowy — i porozmawiać ze specjalistą zanim zaczniesz eksperymentować samodzielnie.
Regularna opieka techniczna nad sklepem — aktualizacje, monitoring wydajności, cache i baza danych — to zdecydowanie tańsze rozwiązanie niż gaszenie pożarów po fakcie. Opieka SLA dla sklepu WooCommerce obejmuje m.in. monitoring Core Web Vitals i reagowanie zanim problemy wydajnościowe wpłyną na sprzedaż.
Chcesz żeby ktoś zadbał o wydajność sklepu regularnie — nie tylko raz na rok? Sprawdź naszą opiekę SLA.
