Średni sklep WooCommerce ładuje się 4–6 sekund na mobile. To nie jest problem hostingu (choć hosting pomaga) — to problem architektury: 40–60 wtyczek, page builder na każdej stronie, niepoptymalizowana baza danych i obrazy w PNG po 2 MB. Poniżej opisujemy, co konkretnie robimy, żeby sklep WooCommerce spadł poniżej 2.5s LCP i przeszedł Core Web Vitals — bez wymiany hostingu i bez przepisywania sklepu od zera.
Dlaczego WooCommerce jest wolny — anatomia problemu
WooCommerce sam w sobie nie jest wolny. Wolny jest WooCommerce z 40 wtyczkami, Elementorem, niepoptymalizowaną bazą i obrazami, które nikt nie skompresował. Typowa strona produktowa generuje 100–200 zapytań SQL i ładuje 2–4 MB zasobów (CSS, JS, obrazy, fonty). To jest za dużo.
Główne źródła wolności, w kolejności wpływu:
- Wtyczki — każda wtyczka dodaje własne CSS i JS do każdej podstrony. Social share widget ładuje 200 KB JS na stronie produktu, choć nikt go tam nie klika. Formularz kontaktowy ładuje się na stronie głównej, choć jest tylko na /kontakt.
- Page builder (Elementor/Divi) — generuje tony nieużywanego CSS/JS. Typowy Elementor dodaje 300–500 KB samego CSS na każdą stronę. Dlatego nie budujemy na page builderach.
- Baza danych — tabela wp_options rośnie w nieskończoność (transients, autoload, revision). Po roku działania sklepu tabela options ma 10 000+ wierszy, z czego 70% to śmieci.
- Obrazy — zdjęcia produktów wrzucane prosto z aparatu (3000x4000 px, 3 MB, JPEG). Brak srcset, brak lazy loading, brak WebP/AVIF.
Krok 1: Audyt wtyczek — usuwanie balastu
Pierwsza rzecz, którą robimy w każdym projekcie optymalizacji WooCommerce: audyt wtyczek z Query Monitor. Instalujemy Query Monitor, otwieramy stronę produktową i sprawdzamy, które wtyczki ładują CSS/JS i ile zapytań SQL generują.
Typowe wyniki audytu:
- Social share plugin — 180 KB JS, 0 użycia na stronie produktu. Wyłączamy na produktach.
- Contact Form 7 — 50 KB JS na każdej stronie (jest potrzebny tylko na /kontakt). Ograniczamy ładowanie do strony kontaktowej.
- Slider plugin — 250 KB JS, używany tylko na stronie głównej. Ograniczamy do strony głównej.
- SEO plugin (Yoast/RankMath) — 100+ KB CSS/JS na froncie. Wyłączamy frontend CSS/JS, zostawiam tylko meta tagi.
Samo ograniczenie ładowania wtyczek do stron, gdzie są potrzebne, zmniejsza rozmiar strony o 30–50%. Bez usuwania wtyczek — tylko inteligentne ładowanie.
Krok 2: Czyszczenie bazy danych
Baza danych WooCommerce po roku działania to bałagan. Co czyścimy:
- Revision posts — WordPress trzyma każdą wersję roboczą każdego produktu. 500 produktów × 10 rewizji = 5000 zbędnych wierszy. Ustawiamy
define('WP_POST_REVISIONS', 3); i czyścimy stare rewizje.
- Transients — tymczasowe dane wtyczek, które zaśmiecają wp_options.
DELETE FROM wp_options WHERE option_name LIKE '%_transient_%' — czasem usuwa tysiące wierszy.
- Autoload w wp_options — WordPress ładuje wszystkie opcje z autoload='yes' przy każdym requeście. Wtyczki ustawiają autoload na dane, które nie są potrzebne na każdej stronie. Audytuję i zmieniam na 'no' gdzie możliwe.
- WooCommerce sessions — stare sesje klientów w bazie. WooCommerce ma cron job do czyszczenia, ale często jest uszkodzony. Czyścimy ręcznie.
Po czyszczeniu bazy TTFB spada o 100–300 ms. Nie jest to rewolucja, ale w połączeniu z Redis Object Cache efekt jest znaczący — Redis cache'uje wyniki zapytań, a czysta baza oznacza szybsze zapytania, które nie są w cache.
Krok 3: Obrazy — największy quick win
Obrazy to najczęściej 60–80% rozmiaru strony produktowej. Co robimy:
- WebP/AVIF — konwertujemy wszystkie obrazy na WebP (70–80% mniejsze niż JPEG) z fallbackiem na JPEG. Używamy ShortPixel lub Imagify na serwerze — nie w przeglądarce.
- Responsive images (srcset) — zamiast jednego obrazu 1200px, generujemy wersje 400, 800, 1200 px. Mobilny użytkownik ładuje 400px zamiast 1200px.
- Lazy loading — obrazy poniżej fold ładują się dopiero, gdy użytkownik scrolluje. Natywne
loading="lazy" na wszystkim poza hero image i pierwszym produktem.
- Preload LCP image — główne zdjęcie produktu dostaje preload w <head>, żeby ładowało się równolegle z CSS, nie po nim.
Efekt: strona produktowa z 3 MB spada do 400–600 KB. LCP poprawia się o 1–2 sekundy.
Krok 4: Checkout — tam, gdzie konwersja się łamie
Checkout WooCommerce to osobny problem wydajnościowy. Domyślny checkout ładuje jQuery, jQuery UI, selectWoo i kilka dodatkowych skryptów. Na mobile to 3–5 sekund ładowania — a klient właśnie chce zapłacić.
Co optymalizujemy:
- Usunięcie zbędnych pól — domyślny checkout ma pola, których sklep nie potrzebuje (Company, Address 2, State). Mniej pól = szybszy render i wyższa konwersja.
- Blokowy checkout (WooCommerce Blocks) — nowy checkout oparty na React, szybszy od klasycznego PHP checkout. Wdrażamy tam, gdzie wtyczki go wspierają.
- Lazy load payment gateways — skrypty Stripe, PayPal, BLIK ładują się dopiero po wyborze metody płatności, nie przy ładowaniu strony.
Krok 5: Cache wielopoziomowy
W WooCommerce cache jest bardziej złożony niż na zwykłej stronie, bo część treści jest dynamiczna (koszyk, ceny, stock):
- Page cache z wykluczeniem dynamicznych stron — cache'uję strony produktowe, kategorie, stronę główną. Wykluczam: koszyk, checkout, moje-konto, wishlist.
- Object cache (Redis) — cache'uje wyniki zapytań SQL. Na WooCommerce z 500+ produktami daje największy efekt na stronach kategorii i wyszukiwaniu.
- Browser cache — ustawiamyy agresywne cache headers na statycznych zasobach (CSS, JS, obrazy):
max-age=31536000 dla plików z hash w nazwie.
- CDN — Cloudflare lub BunnyCDN przed serwerem. Statyczne zasoby serwowane z edge, dynamiczne przechodzą do origin. Na polskim rynku CDN daje mniejszy efekt niż na globalnym, ale nadal 50–100 ms szybciej.
Z naszej praktyki — konkretne optymalizacje WooCommerce
Trzy realne przypadki optymalizacji wydajności sklepów WooCommerce z naszego portfolio:
- Nobobobo (artykuły dla dzieci) — sklep z biblioteką 7800 plików graficznych uploadowanych bezpośrednio z aparatów producentów. Workflow optymalizacji: audyt biblioteki, backup pełny, konwersja wszystkich zdjęć do WebP z fallback JPG (jakość 82), wdrożenie Redis Object Cache dla cache zapytań SQL. Łączna oszczędność wagi biblioteki to dziesiątki gigabajtów, TTFB strony głównej spadł z poziomu „niedopuszczalny" do akceptowalnego zgodnie z Google PageSpeed Insights.
- Podsztanga (szkolenia trójboju siłowego) — wymiana ciężkiego motywu WoodMart na lekki Hello Theme + custom child theme. Wyjściowy wynik PageSpeed mobile był na poziomie 42/100 (czerwona strefa Lighthouse), LCP osiągał 9 sekund. Po migracji motywu i optymalizacji assets wyniki przeszły do akceptowalnego zielonego. Dla sklepu, w którym klient kupuje z telefonu na siłowni w przerwach treningowych, to było absolutnie krytyczne.
- huka.com.pl (akcesoria premium dla psów) — odchudzenie sklepu przez wyłączenie 4 wtyczek analitycznych (Site Kit, PixelYourSite, GTM4WP, Google for WooCommerce — pomiar) i zastąpienie ich jednym custom kodem w functions.php. Każda wyłączona wtyczka to mniej zapytań SQL i mniej JavaScript do parsowania.
Wzorzec we wszystkich trzech: mniej wtyczek + agresywny cache + WebP zamiast PNG/JPG. Hosting i CDN pomagają, ale to są szlifierki, nie fundament.
Jeśli potrzebujesz pomocy z optymalizacją szybkości sklepu — audytujemy wydajność, wdrażamy poprawki i monitorujemy Core Web Vitals po zmianach.
