Szybkość WooCommerce — jak przyspieszyć sklep bez wymiany hostingu

Ś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.

Jeśli potrzebujesz pomocy z optymalizacją szybkości sklepu — audytujemy wydajność, wdrażamy poprawki i monitorujemy Core Web Vitals po zmianach.