Jak przyspieszyć sklep WooCommerce pod Core Web Vitals

Dlaczego Core Web Vitals to problem WooCommerce, a nie WordPressa

Zanim ktoś napisze w komentarzu “WordPress jest wolny”: nie, nie jest. Prosta strona firmowa na WordPressie bez trudu osiąga 90+ punktów w PageSpeed Insights. Problem zaczyna się, gdy na ten sam WordPress nakładasz WooCommerce z 40 wtyczkami, galerię zdjęć produktów w rozmiarze 3000x3000 px, cztery skrypty marketingowe i motyw premium, który ciągnie za sobą Slick Slider, Owl Carousel i jeszcze jakąś bibliotekę animacji “żeby było ładnie”.

WooCommerce ma trzy systemowe problemy z wydajnością, których nie mają platformy zamknięte typu Shopify czy Shoper:

• brak kontroli nad jakością wtyczek - każda wtyczka dodaje własne pliki CSS i JS, niezależnie od tego, czy są potrzebne na danej podstronie. 40 wtyczek to potencjalnie 40 osobnych arkuszy stylów i 40 skryptów ładowanych na każdej stronie
• hosting zależny od użytkownika - Shopify ma własną infrastrukturę zoptymalizowaną pod e-commerce. W WooCommerce możesz postawić sklep z 5000 produktów na hostingu współdzielonym za 15 zł miesięcznie i nikt Cię nie ostrzeże, że to nie zadziała
• brak automatycznej optymalizacji obrazów - WooCommerce nie konwertuje zdjęć do WebP, nie kompresuje ich przy uploadzie i nie wymusza odpowiednich rozmiarów. Wszystko trzeba skonfigurować samodzielnie lub przez wtyczki

Efekt? Typowy sklep WooCommerce na hostingu współdzielonym, z popularnym motywem premium i standardowym zestawem wtyczek, osiąga 25-40 punktów w PageSpeed Insights na mobile. Google ocenia takie wyniki jako “poor” we wszystkich trzech metrykach Core Web Vitals.

Dobra wiadomość: WooCommerce można przyspieszyć do poziomu 80-95 punktów. Wymaga to systematycznej pracy w czterech obszarach: hosting, obrazy, JavaScript i stabilność wizualna. Poniżej opisuję każdy z nich.

LCP: co blokuje ładowanie głównego elementu strony

LCP (Largest Contentful Paint) mierzy moment, w którym największy widoczny element strony pojawia się na ekranie. Na stronach produktów WooCommerce to zazwyczaj zdjęcie produktu. Na stronach kategorii - pierwszy obraz w siatce produktów lub baner kategorii. Na stronie głównej - hero image lub slider.

Cel Google: LCP poniżej 2,5 sekundy. Typowy sklep WooCommerce bez optymalizacji: 4-8 sekund.

Hosting: fundament, którego nie przeskoczysz

Zanim zaczniesz optymalizować frontend, sprawdź TTFB (Time to First Byte). Jeśli serwer potrzebuje 800 ms, żeby w ogóle zacząć wysyłać dane, to żadna wtyczka cache nie da Ci LCP poniżej 2,5 s.

Hosting współdzielony za 10-30 zł miesięcznie nie nadaje się do sklepu z setkami produktów. Kropka. Nie ma tu miejsca na dyskusję. Przejście na hosting zarządzany dla WordPressa (Cloudways, Kinsta, Flavius) to zazwyczaj jednorazowa zmiana, która obniża TTFB z 600-1200 ms do 150-300 ms. Koszt to 80-250 zł miesięcznie, ale efekt jest natychmiastowy i trwały.

Na serwerze upewnij się, że masz:

• PHP 8.1 lub nowsze (przejście z 7.4 na 8.1 to ok. 20-30% szybsze wykonywanie kodu)
• włączony OPcache (sprawdzisz w phpinfo() - opcache.enable powinno być 1)
• Redis lub Memcached jako object cache (szczególnie ważne przy katalogu powyżej 1000 produktów)

Cache na poziomie strony: WP Rocket lub LiteSpeed Cache

Wtyczka cache to absolutne minimum. WP Rocket jest płatna (ok. 250 zł/rok), ale działa od razu po instalacji bez konfiguracji. Generuje statyczne wersje stron HTML, dzięki czemu serwer nie musi przy każdej wizycie odpytywać bazy danych i uruchamiać PHP.

Jeśli Twój hosting używa serwera LiteSpeed (wielu polskich hostingów to robi), zamiast WP Rocket zainstaluj LiteSpeed Cache. Jest bezpłatny i współpracuje z serwerem na poziomie, którego żadna inna wtyczka nie osiągnie.

Co skonfigurować w wtyczce cache:

• page cache dla zalogowanych użytkowników powinien być wyłączony (koszyk i dane użytkownika muszą być dynamiczne)
• cache powinien się automatycznie czyścić po aktualizacji produktu (zmiana ceny, stanu magazynowego)
• preload cache - wtyczka powinna samodzielnie odwiedzać strony po wyczyszczeniu cache, żeby odbudować statyczne wersje

Obrazy: format, rozmiar, preload

Zdjęcia produktów to najczęstsza przyczyna wolnego LCP w WooCommerce. Trzy kroki, które rozwiązują 90% problemów:

Konwersja do WebP lub AVIF. Wtyczki ShortPixel lub Imagify automatycznie konwertują przesłane obrazy do nowoczesnych formatów. WebP jest o 25-35% lżejszy od JPEG przy porównywalnej jakości. AVIF jeszcze bardziej, ale wsparcie przeglądarek jest węższe. ShortPixel w wersji bezpłatnej obsługuje 100 obrazów miesięcznie. Dla sklepu z dużym katalogiem potrzebujesz planu płatnego (od ok. 20 zł/miesiąc).

Prawidłowe rozmiary. Jeśli przesyłasz zdjęcia 3000x3000 px, a wyświetlasz je w kontenerze 600x600 px, przeglądarka pobiera pięciokrotnie za dużo danych. WordPress generuje miniaturki automatycznie, ale domyślne rozmiary mogą nie pasować do Twojego motywu. Sprawdź w Ustawienia > Media i dostosuj rozmiary do faktycznych wymiarów kontenerów w motywie.

Preload hero image. Główne zdjęcie produktu (to, które determinuje LCP) powinno mieć w sekcji <head> tag <link rel="preload" as="image">. To mówi przeglądarce: zacznij pobierać ten obraz natychmiast, nie czekaj na parsowanie CSS i JS. WP Rocket w wersji 3.12+ robi to automatycznie. Jeśli używasz innej wtyczki cache, dodaj preload ręcznie w functions.php lub przez wtyczkę typu Pre* Party Resource Hints.

CDN: kiedy ma sens

CDN (Content Delivery Network) przyspiesza dostarczanie zasobów statycznych - obrazów, CSS, JS, fontów - przez serwowanie ich z serwera geograficznie bliskiego użytkownikowi. Dla polskiego sklepu z polskimi klientami CDN nie jest krytyczny (Twój serwer jest prawdopodobnie w Polsce lub Niemczech). Ale jeśli masz ruch z wielu krajów lub po prostu chcesz odciążyć serwer, Cloudflare w wersji bezpłatnej wystarczy na początek.

INP: dlaczego sklep nie reaguje na kliknięcia

INP (Interaction to Next Paint) mierzy, jak szybko strona reaguje na interakcje użytkownika: kliknięcia przycisków, otwieranie menu, zmianę wariantu produktu. Cel Google: poniżej 200 ms. Typowy sklep WooCommerce z motywem premium i standardowym zestawem wtyczek: 300-600 ms.

Główny winowajca: za dużo JavaScriptu

Każda wtyczka WooCommerce dodaje swoje skrypty JS. I większość z nich ładuje się na każdej stronie, nawet tam, gdzie nie są potrzebne. Wtyczka galerii produktów ładuje swój JS na stronie kontaktowej. Wtyczka kalkulatora wysyłki ładuje się na blogu. Slider na stronie głównej ciągnie bibliotekę Slick na każdej podstronie. To tak, jakbyś nosił plecak z narzędziami do pracy, do sklepu i do łóżka.

Pracowałem ze sklepem, który miał 38 osobnych plików JavaScript ładujących się na stronie produktowej. 38. Po audycie i wyłączeniu zbędnych skryptów czas reakcji na kliknięcie spadł z 450 ms do 160 ms. Bez zmiany hostingu, bez zmiany motywu. Tylko posprzątanie bałaganu.

To nie tylko marnowanie transferu. JavaScript blokuje główny wątek przeglądarki. Gdy przeglądarka parsuje i wykonuje 1-2 MB JavaScriptu, nie jest w stanie reagować na kliknięcia użytkownika. Stąd wysoki INP.

Diagnoza: co dokładnie blokuje wątek

Otwórz Chrome DevTools (F12), przejdź do zakładki Performance, kliknij Record i wykonaj typowe interakcje na stronie (kliknij “dodaj do koszyka”, zmień wariant, otwórz menu). Zatrzymaj nagrywanie i spójrz na wykres Main Thread. Długie żółte bloki to wykonywanie JavaScriptu. Najedź na nie, żeby zobaczyć, który skrypt jest odpowiedzialny.

Najczęstsi winowajcy w WooCommerce:

• motywy premium z wbudowanymi animacjami i bibliotekami (Flatsome, Woodmart - świetne wizualnie, ciężkie technicznie)
• Google Tag Manager z dziesiątkami tagów (Hotjar, Facebook Pixel, Google Ads remarketing, LiveChat)
• wtyczki typu “wszystko w jednym” (Jetpack, Elementor, WPBakery), które ładują ogromne pakiety JS

Rozwiązanie: defer, async, selective loading

Odroczenie ładowania skryptów. WP Rocket i inne wtyczki cache mają opcję “Defer JavaScript” lub “Delay JavaScript”. To powoduje, że skrypty nie blokują renderowania strony, tylko ładują się po wyświetleniu głównej treści. Włącz to dla wszystkich skryptów poza krytycznymi (np. wtyczka cache sama wyłącza defer dla skryptów niezbędnych do działania strony).

Selektywne ładowanie skryptów. Wtyczka Asset CleanUp (Perfmatters robi to samo, ale jest płatna) pozwala wyłączyć konkretne skrypty na konkretnych podstronach. Nie potrzebujesz skryptu slidera na stronie produktu? Wyłącz go tam. Wtyczka kalkulatora wysyłki nie jest potrzebna na blogu? Wyłącz ją na wpisach blogowych.

Redukcja wtyczek. To najtrudniejsze, ale najskuteczniejsze rozwiązanie. Przejrzyj listę aktywnych wtyczek i zadaj sobie pytanie: czy ta wtyczka jest konieczna? Czy nie ma lżejszej alternatywy? Czy trzy wtyczki do social sharing nie mogłyby być zastąpione jedną linijką kodu HTML? Szczegółowy proces audytu wtyczek opisuję w artykule o audycie technicznym WooCommerce.

CLS: dlaczego strona “skacze”

CLS (Cumulative Layout Shift) mierzy niestabilność wizualną. Gdy elementy strony zmieniają pozycję po załadowaniu, użytkownik może kliknąć nie tam, gdzie chciał, albo stracić miejsce w tekście. Cel Google: poniżej 0,1. Ten problem jest stosunkowo łatwy do naprawienia, jeśli znasz jego przyczyny.

Obrazy bez wymiarów

HTML wymaga atrybutów width i height w tagu <img>, żeby przeglądarka mogła zarezerwować miejsce na obraz zanim go pobierze. WordPress domyślnie dodaje te atrybuty, ale niektóre motywy je usuwają (zwłaszcza w galeriach produktów i sliderach). Sprawdź źródło strony (Ctrl+U) i wyszukaj tagi <img> bez width i height.

Jeśli motyw usuwa wymiary, masz dwa wyjścia: dodać je z powrotem przez filtr w functions.php lub użyć CSS z aspect-ratio, który rezerwuje miejsce na obraz na podstawie proporcji.

Webfonty i font-display: swap

Jeśli ładujesz Google Fonts zewnętrznie (przez link w <head>), przeglądarka najpierw wyświetla tekst fontem systemowym, a po pobraniu webfonta podmienia go. Ta podmiana powoduje przesunięcie, bo webfont ma inne metryki niż font systemowy.

Rozwiązanie: dodaj parametr &display=swap do URL-a Google Fonts (jeśli go jeszcze nie masz) i rozważ hostowanie fontów lokalnie. Wtyczki typu OMGF (Optimize My Google Fonts) pobierają fonty Google na Twój serwer i serwują je lokalnie, co eliminuje dodatkowe zapytanie DNS i przyspiesza ładowanie.

Dynamiczne banery i powiadomienia

Pasek z informacją o darmowej dostawie, baner cookies, powiadomienie o promocji - te elementy często wstawiają się w DOM po załadowaniu strony i przesuwają resztę treści w dół. Dwa podejścia:

• rezerwacja przestrzeni - jeśli wiesz, że baner ma 50 px wysokości, dodaj w CSS placeholder o tej wysokości, który zniknie po załadowaniu banera
• overlay zamiast push - wyświetlaj powiadomienia jako nakładkę (position: fixed lub sticky na dole ekranu), a nie jako element wpychany na górę strony

Rekomendowany stos technologiczny

Po pracy z dziesiątkami sklepów WooCommerce wypracowałem stos, który konsekwentnie daje dobre wyniki. Nie jest to jedyna słuszna droga, ale za każdym razem, kiedy klient pyta “co zainstalować?”, zaczynam od tego:

Hosting: Cloudways (VPS Vultr lub DigitalOcean), Kinsta lub Flavius. Budżet: 80-250 zł/miesiąc.

Cache: WP Rocket (jeśli serwer Apache/Nginx) lub LiteSpeed Cache (jeśli serwer LiteSpeed). WP Rocket kosztuje ok. 250 zł/rok. LiteSpeed Cache jest bezpłatny.

Obrazy: ShortPixel lub Imagify do kompresji i konwersji WebP. ShortPixel w planie płatnym od ok. 20 zł/miesiąc. Imagify ma bezpłatny plan do 20 MB/miesiąc.

CDN: Cloudflare w wersji bezpłatnej. Dla większych sklepów Cloudflare Pro (ok. 80 zł/miesiąc) z dodatkowymi regułami cache.

Optymalizacja skryptów: Asset CleanUp (bezpłatny) lub Perfmatters (ok. 100 zł/rok) do selektywnego wyłączania skryptów na podstronach.

Object cache: Redis (dostępny na większości hostingów zarządzanych) z wtyczką Redis Object Cache.

Łączny koszt tego stosu to 200-500 zł miesięcznie. Dla sklepu, który generuje przychody z ruchu organicznego, to inwestycja z szybkim zwrotem.

Monitoring: jak śledzić postępy

Optymalizacja Core Web Vitals to nie jednorazowa akcja. Każda aktualizacja wtyczki, nowy baner promocyjny czy zmiana motywu może pogorszyć wyniki. Potrzebujesz stałego monitoringu.

Google Search Console

Raport Core Web Vitals w GSC (Jakość strony > Core Web Vitals) pokazuje dane z rzeczywistych użytkowników (dane polowe, CrUX). To jedyne dane, które Google wykorzystuje do oceny wydajności w kontekście rankingów. Raport aktualizuje się z opóźnieniem 28 dni, więc nie zobaczysz efektów optymalizacji od razu.

Zwróć uwagę na podział na mobile i desktop. Sklepy WooCommerce mają zazwyczaj dobre wyniki na desktopie i fatalne na mobile. Google ocenia je osobno, ale ranking mobilny opiera się na danych mobilnych, a ponad 60% ruchu e-commerce pochodzi właśnie z urządzeń mobilnych.

PageSpeed Insights i Lighthouse

PageSpeed Insights (pagespeed.web.dev) daje dwa zestawy danych: laboratoryjne (symulacja) i polowe (dane CrUX). Dane laboratoryjne przydają się do diagnozowania problemów. Dane polowe to prawdziwy obraz wydajności.

Sprawdzaj wyniki po każdej większej zmianie: aktualizacji motywu, instalacji nowej wtyczki, dodaniu nowego skryptu marketingowego. Zapisuj wyniki, żebyś mógł porównywać w czasie.

Biblioteka web-vitals.js

Jeśli chcesz mieć własne, ciągłe dane o wydajności, zainstaluj bibliotekę web-vitals.js i wysyłaj metryki do Google Analytics 4 lub własnej bazy danych. Dzięki temu zobaczysz rozkład LCP, INP i CLS dla poszczególnych podstron i segmentów użytkowników (mobile vs desktop, nowi vs powracający).

Konfiguracja jest prosta: kilka linii kodu w pliku functions.php lub w Google Tag Manager. Google ma oficjalną dokumentację integracji web-vitals.js z GA4.

Podsumowanie: kolejność działań

Jeśli Twój sklep WooCommerce ma słabe wyniki Core Web Vitals, zacznij od tego:

1. zmierz aktualne wyniki w PageSpeed Insights (mobile) i zapisz je
2. sprawdź TTFB. Jeśli powyżej 600 ms, zmień hosting. To da największy efekt
3. zainstaluj i skonfiguruj WP Rocket lub LiteSpeed Cache
4. wdróż kompresję obrazów (ShortPixel/Imagify) i konwersję do WebP
5. włącz defer JavaScript w wtyczce cache
6. przejrzyj wtyczki i wyłącz zbędne skrypty na podstronach (Asset CleanUp)
7. napraw CLS: wymiary obrazów, font-display: swap, placeholdery dla banerów
8. zmierz ponownie i porównaj z punktem wyjścia

Cały proces, od diagnozy do wdrożenia, zajmuje typowo 2-4 tygodnie. Efekty w postaci poprawy wyników PageSpeed zobaczysz natychmiast. Efekty w danych polowych GSC (CrUX) pojawią się po 28 dniach. Wpływ na rankingi - stopniowo, w ciągu kolejnych tygodni.

Jeśli prowadzisz sklep na WooCommerce i szukasz specjalisty, który przeprowadzi audyt wydajności i wdroży optymalizacje, opisujemy nasze podejście do SEO dla WooCommerce tutaj. Pełny audyt techniczny krok po kroku znajdziesz w artykule SEO dla WooCommerce: kompletny audyt techniczny.

FAQ

Czy WP Rocket wystarczy, żeby naprawić Core Web Vitals?

WP Rocket to dobry start, ale sam nie rozwiąże wszystkich problemów. Cache stron i odroczenie JavaScriptu poprawia LCP i częściowo INP. Ale jeśli masz wolny hosting, niezoptymalizowane obrazy lub motyw, który ładuje 1 MB JavaScriptu, WP Rocket nie zrobi cudów. Traktuj go jako jeden element stosu, nie jako jedyne rozwiązanie.

Czy zmiana motywu jest konieczna?

Nie zawsze, ale bywa konieczna. Motywy typu Flatsome, Woodmart czy Avada mają rozbudowany builder i dużo wbudowanych funkcji, co oznacza ciężki JavaScript. Jeśli po optymalizacji cache, obrazów i skryptów nadal nie osiągasz dobrych wyników INP, motyw jest prawdopodobnie wąskim gardłem. Alternatywy to lżejsze motywy, np. GeneratePress lub Flavor. Zmiana motywu to jednak duży projekt (przepisanie szablonów, testowanie integracji z wtyczkami), więc traktuj to jako ostateczność, gdy inne optymalizacje nie dają efektu.

Ile punktów PageSpeed realnie da się osiągnąć na WooCommerce?

Na mobile: 75-95 punktów jest realne przy dobrym hostingu, zoptymalizowanych obrazach i kontrolowanej liczbie wtyczek. 100 punktów na stronie produktu WooCommerce jest praktycznie nieosiągalne, bo WooCommerce z natury ładuje skrypty do koszyka, wariantów i galerii. Na desktopie 90-100 to standard po optymalizacji.

Czy Cloudflare spowalnia stronę dla polskich użytkowników?

Nie, pod warunkiem że masz włączony Polish datacenter. Cloudflare ma punkt obecności w Warszawie, więc zasoby serwowane przez CDN docierają do polskich użytkowników z minimalnym opóźnieniem. Jedyny scenariusz, w którym Cloudflare może spowolnić stronę, to agresywne reguły WAF, które dodają opóźnienie przy każdym żądaniu. W wersji bezpłatnej to nie problem.

Jak często sprawdzać Core Web Vitals?

Minimum: raz w miesiącu w Google Search Console (dane polowe) i po każdej większej zmianie na stronie w PageSpeed Insights (dane laboratoryjne). Jeśli wdrożysz web-vitals.js z GA4, masz ciągły monitoring bez dodatkowego wysiłku. Ważne jest reagowanie na regresje: jeśli po aktualizacji wtyczki LCP wzrosło o sekundę, nie czekaj miesiąca na dane polowe. Diagnozuj i naprawiaj od razu na podstawie danych laboratoryjnych.