Z 40 na 98 PageSpeed: jak zoptymalizowałem sklep WooCommerce

Każda sekunda ma znaczenie w e-commerce. Dla sklepu WooCommerce przetwarzającego tysiące zamówień miesięcznie, to bezpośrednio przekłada się na utracone przychody. To studium przypadku dokumentuje, jak w WPPoland przekształciłem borykający się z problemami europejski sklep meblowy e-commerce z wyniku PageSpeed 40 na 98 - i co to oznaczało dla ich wyników finansowych.

#Sklep meblowy na WooCommerce w Europie

Mój klient prowadzi średniej wielkości sklep meblowy online obsługujący klientów w Europie Środkowej i Zachodniej. Z katalogiem ponad 3500 produktów i 12 000 zdjęć produktów stawka była wysoka. Ich sklep WooCommerce rozrastał się organicznie przez pięć lat, gromadząc dług techniczny z każdą instalacją wtyczki, dostosowaniem motywu i integracją z usługami zewnętrznymi.

Na początku 2026 roku sklep tracił przychody. Konkurenci z szybszymi stronami wyprzedzali ich w wynikach wyszukiwania, a użytkownicy mobilni - stanowiący 64 procent ruchu - masowo opuszczali stronę.

#Dlaczego sklep WooCommerce działał wolno

Kiedy po raz pierwszy przeprowadziłem audyt strony, znalazłem znany, ale poważny wzorzec degradacji wydajności:

• 38 aktywnych wtyczek, wiele z nakładającą się funkcjonalnością
• Hosting współdzielony bez cache na poziomie serwera
• Niezoptymalizowana baza danych z ponad 2,3 miliona wygasłych transientów
• 12 000 zdjęć produktów serwowanych jako nieskompresowane pliki PNG i JPEG
• Brak CDN - wszystkie zasoby serwowane z jednego serwera w Niemczech
• JavaScript blokujący renderowanie z 14 wtyczek ładowanych na każdej stronie
• 5-krokowy proces kasy z 22 polami formularza

Rezultatem była strona, która na urządzeniach mobilnych sprawiała wrażenie zepsutej. Strony ładowały się 8 sekund, układ skakał podczas renderowania elementów, a proces kasy był tak uciążliwy, że 68 procent odwiedzających opuszczało stronę przed dokonaniem zakupu.

#Metryki przed optymalizacją

#Jak przyspieszyć WooCommerce w 7 fazach

Stosuję systematyczne, oparte na danych podejście do optymalizacji szybkości WordPress. Każda faza bazuje na poprzedniej, a wpływ każdej zmiany mierzę w izolacji przed przejściem do następnej.

#Faza 1: audyt techniczny (dni 1-3)

Zanim dotknąłem pojedynczej linii kodu, spędziłem trzy dni profilując każdy aspekt strony:

• Analiza GTmetrix Waterfall w celu identyfikacji najdłuższych łańcuchów zapytań
• Testy WebPageTest z wielu lokalizacji: Frankfurt, Londyn i Warszawa
• Panel wydajności Chrome DevTools do profilowania aktywności głównego wątku
• Logowanie zapytań do bazy danych przy użyciu wtyczki Query Monitor w celu znalezienia wolnych zapytań
• Profilowanie wtyczek w celu zmierzenia wpływu każdej wtyczki na czas ładowania strony

Audyt ujawnił, że 73 procent czasu ładowania było przypisywalne trzem czynnikom: niezoptymalizowane obrazy (31 procent), nadmierny JavaScript (26 procent) i wolne zapytania do bazy danych (16 procent).

#Faza 2: optymalizacja serwera (dni 4-7)

Fundamentem każdej szybkiej strony jest serwer. Przeniosłem klienta z hostingu współdzielonego na dedykowany VPS z następującym stosem technologicznym:

• Serwer LiteSpeed z obsługą HTTP/3 i QUIC
• Redis Object Cache do trwałego cache obiektów WordPress
• MariaDB 11.4 że zoptymalizowaną konfiguracją my.cnf
• PHP 8.3 z włączonym preloadingiem OPcache

Konfiguracja LiteSpeed zawierała specjalne dostrojenie dla WooCommerce:

# Reguły cache LiteSpeed dla WooCommerce
<IfModule LiteSpeed>
CacheLookup on RewriteRule .* - [E=Cache-Control:no-autoflush] RewriteRule ^/cart.* - [E=Cache-Control:no-cache] RewriteRule ^/checkout.* - [E=Cache-Control:no-cache] RewriteRule ^/ja-account.* - [E=Cache-Control:no-cache]
</IfModule>

Konfiguracja Redis została dostrojona do obsługi sesji WooCommerce:

// Dodatki do wp-config.php dla Redis
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_MAXTTL', 86400);
define('WP_REDIS_PREFIX', 'wc_store_');
define('WP_REDIS_SELECTIVE_FLUSH', true);

Wpływ po Fazie 2: TTFB spadł z 2,4 sekundy do 180 milisekund.

#Faza 3: czyszczenie bazy danych (dni 8-11)

Pięć lat eksploatacji pozostawiło bazę danych w stanie krytycznym. Przeprowadziłem metodyczne czyszczenie:

1. Usunięcie 2,3 miliona wygasłych transientów - tabela wp_options urosła do 847 MB
2. Optymalizacja 47 wolnych zapytań zidentyfikowanych podczas fazy audytu
3. Dodanie brakujących indeksów do tabel wp_postmeta i wp_wc_order_stats
4. Czyszczenie osieroconych meta postów - 340 000 wierszy metadanych dla usuniętych produktów
5. Konwersja tabel na InnoDB tam, gdzie nadal używano MyISAM

Niestandardowe indeksy znacząco poprawiły wyszukiwanie i filtrowanie produktów:

-- Niestandardowe indeksy dla zapytań o produkty WooCommerce
ALTER TABLE wp_postmeta ADD INDEX idx_meta_lookup (meta_key, meta_value(32));
ALTER TABLE wp_wc_product_meta_lookup ADD INDEX idx_price_stock (min_price, max_price, stock_status);
ALTER TABLE wp_woocommerce_order_items ADD INDEX idx_order_type (order_id, order_item_type);

Wpływ po Fazie 3: Czas zapytań do bazy danych spadł o 84 procent, a tabela wp_options skurczyła się z 847 MB do 12 MB.

#Faza 4: optymalizacja obrazów (dni 12-15)

Przy 12 000 zdjęć produktów, ta faza miała największy indywidualny wpływ na wagę strony:

• Konwersja wszystkich obrazów do AVIF z fallbackiem WebP dla starszych przeglądarek
• Wdrożenie responsywnego srcset z breakpointami na 320, 640, 960, 1280 i 1920 pikseli
• Dodanie lazy loading z natywnym loading="lazy" dla wszystkich obrazów poniżej widocznego obszaru
• Ustawienie jawnych wymiarów na każdym tagu <img> w celu wyeliminowania CLS z ładowania obrazów
• Wdrożenie placeholderów blur-up przy użyciu Low Quality Image Placeholders (LQIP)

Przetwarzanie obrazów zautomatyzowałem dwoma filtrami WordPressa i WP-CLI:

// Wyjście AVIF dla generowanych rozmiarów obrazów (WordPress 6.5+)
add_filter('image_editor_output_format', function ($formats) {
    $formats['image/jpeg'] = 'image/avif';
    $formats['image/png'] = 'image/avif';
    return $formats;
});

// Jakość AVIF 75, pozostałe formaty bez zmian
add_filter('wp_editor_set_quality', function ($quality, $mime_type) {
    return 'image/avif' === $mime_type ? 75 : $quality;
}, 10, 2);

wp media regenerate --yes

Wpływ po Fazie 4: Średnia waga strony spadła z 6,8 MB do 1,2 MB. LCP poprawiło się z 5,1 sekundy (po optymalizacji serwera) do 1,4 sekundy.

#Faza 5: audyt JavaScript (dni 16-19)

Audyt JavaScript był chirurgiczny. Skategoryzowałem każdy skrypt na stronie:

Dla skryptów analitycznych wdrożyłem wzorzec opóźnionego ładowania:

// Opóźnij niekrytyczne skrypty do interakcji użytkownika
const loadDeferredScripts = () => {
  const scripts = document.querySelectorAll('script[data-defer-src]');
  scripts.forEach(script => {
    const newScript = document.createElement('script');
    newScript.src = script.dataset.deferSrc;
    newScript.async = true;
    document.body.appendChild(newScript);
  });
};

['mouseover', 'touchstart', 'scroll', 'keydown'].forEach(event => {
  window.addEventListener(event, loadDeferredScripts, { once: true });
});

Wyeliminowałem również CSS blokujący renderowanie przez inline’owanie krytycznych stylów i odroczenie pełnego arkusza stylów:

<link rel="preload" href="/wp-content/themes/theme/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/wp-content/themes/theme/style.css"></noscript>

Wpływ po Fazie 5: INP spadł z 680ms do 62ms. Całkowity payload JavaScript zmniejszony o 78 procent.

#Faza 6: optymalizacja kasy (dni 20-23)

Szybka strona nie ma znaczenia, jeśli kasa zabija konwersje. Przebudowałem cały przepływ kasowy:

• Redukcja z 5 kroków do 2 (wysyłka + płatność na jednej stronie, potwierdzenie na następnej)
• Usunięcie 14 zbędnych pól formularza (nazwa firmy, telefon 2, fax itp.)
• Dodanie ekspresowej płatności (Apple Pay, Google Pay, Klarna)
• Wdrożenie autouzupełniania adresu przy użyciu Google Places API
• Dodanie walidacji formularza w czasie rzeczywistym w celu zapobiegania błędom przy wysyłaniu

// Usunięcie zbędnych pól kasy WooCommerce
add_filter('woocommerce_checkout_fields', function ($fields) {
    unset($fields['billing']['billing_company']);
    unset($fields['billing']['billing_phone_2']);
    unset($fields['billing']['billing_fax']);
    unset($fields['order']['order_comments']);
    return $fields;
});

// Dodanie obsługi ekspresowej bramki płatniczej
add_action('woocommerce_review_order_before_payment', function () {
    if (class_exists('WC_Payment_Gateway')) {
        echo '<div id="express-checkout-buttons" class="express-payment-wrapper">';
        do_action('woocommerce_express_checkout_buttons');
        echo '</div>';
    }
});

Wpływ po Fazie 6: Współczynnik porzucania koszyka spadł o 34 procent. Średni czas realizacji zamówienia skrócił się z 4 minut 12 sekund do 1 minuty 38 sekund.

#Faza 7: CDN i edge caching (dni 24-28)

Ostatnia warstwa optymalizacji zapewniła, że zyski wydajności były spójne na wszystkich rynkach europejskich:

• Cloudflare Pro z niestandardowymi regułami stron dla WooCommerce
• Edge caching dla statycznych stron produktów z 4-godzinnym TTL
• Nagłówki cache przeglądarki z cache-bustingiem przez haszowanie zawartości
• Kompresja Brotli włączona na edge dla wszystkich zasobów tekstowych
• Early Hints (103) dla krytycznych zasobów

# Reguły stron Cloudflare
URL: *example.com/product/*
Cache Level: Cache Everything
Edge Cache TTL: 4 hours
Browser Cache TTL: 1 hour

URL: *example.com/cart*
Cache Level: Bypass

URL: *example.com/checkout*
Cache Level: Bypass

Wpływ po Fazie 7: Globalny TTFB spadł poniżej 100 milisekund. Użytkownicy w Europie Zachodniej doświadczali pełnego ładowania stron poniżej 800ms.

#PageSpeed WooCommerce przed i po optymalizacji

Po czterech tygodniach systematycznej optymalizacji transformacja była dramatyczna:

#Jak czytać wyniki Core Web Vitals sklepu WooCommerce

Kolumna z oceną w tabelach powyżej opiera się na progach, które Google publikuje na web.dev. Dobry Largest Contentful Paint następuje w ciągu 2,5 sekundy od rozpoczęcia ładowania strony, dobry Interaction to Next Paint wynosi 200 milisekund lub mniej, a dobry Cumulative Layout Shift 0,1 lub mniej. Google ocenia każdą metrykę na 75. percentylu wczytań strony, osobno dla urządzeń mobilnych i komputerów, więc strona przechodzi tylko wtedy, gdy trzy na cztery wizyty mieszczą się w progu.

Wyniki PageSpeed 40 i 98 to liczby innego rodzaju. To wyniki laboratoryjne z symulowanego wczytania, przydatne do porównywania kolejnych wersji witryny w trakcie projektu takiego jak ten. Ten sam przewodnik web.dev zaznacza, że pomiar laboratoryjny nie zastępuje pomiaru terenowego, bo Core Web Vitals to metryki terenowe zbierane od prawdziwych odwiedzających. Po wdrożeniu liczą się więc dane terenowe w PageSpeed Insights i raport Core Web Vitals w Search Console, kilka tygodni później, gdy zbierze się dość prawdziwych wizyt.

#Jak szybkość strony wpływa na konwersję sklepu

Metryki techniczne są satysfakcjonujące, ale metryki biznesowe uzasadniają inwestycję:

• Współczynnik konwersji wzrósł mniej więcej dwukrotnie
• Przychody z urządzeń mobilnych wzrosły - użytkownicy mobilni mogli wreszcie robić zakupy bez frustracji
• Współczynnik odrzuceń spadł mniej więcej o połowę - odwiedzający zostawali i przeglądali zamiast wychodzić
• Projekt zwrócił się w tygodniach, nie w kwartałach
• Średnia wartość zamówienia wzrosła - szybsze przeglądanie produktów prowadziło do większej liczby produktów w koszyku
• Ruch organiczny wzrósł - poprawione Core Web Vitals przyczyniły się do lepszych pozycji w wyszukiwarce w ciągu 8 tygodni

#Wnioski z optymalizacji wydajności WooCommerce

Każdy projekt optymalizacji uczy mnie czegoś nowego. Oto kluczowe wnioski z tego zlecenia:

#1. Jak hosting wpływa na szybkość WooCommerce

Żadna ilość optymalizacji front-endu nie zrekompensuje wolnego serwera. Migracja z hostingu współdzielonego na dostrojony VPS LiteSpeed odpowiadała za 35 procent całkowitej poprawy wydajności.

#2. Dlaczego regularnie czyścić bazę danych WooCommerce

Sklepy WooCommerce generują ogromne ilości danych transientowych. Bez regularnego czyszczenia tabela wp_options staje się wąskim gardłem wpływającym na każde ładowanie strony. Zautomatyzowane cotygodniowe czyszczenie powinno być standardem dla każdego sklepu WooCommerce.

#3. Jak wtyczki spowalniają sklep WooCommerce

Spośród 38 zainstalowanych wtyczek, 14 było nieużywanych, nadmiarowych lub możliwych do zastąpienia lekkimi fragmentami kodu. Każda wtyczka dodaje zapytania do bazy danych, JavaScript i CSS - nawet gdy jej funkcjonalność nie jest potrzebna na bieżącej stronie.

#4. Ile obrazy AVIF zmniejszają wagę strony

Konwersja do AVIF i wdrożenie responsywnych obrazów zmniejszyły wagę strony o ponad 80 procent. Ta pojedyncza zmiana, która może być w dużej mierze zautomatyzowana, dostarcza najbardziej widoczną poprawę dla użytkowników końcowych.

#5. Jak UX kasy wpływa na przychody sklepu

Redesign kasy, choć nie jest tradycyjną optymalizacją „wydajności”, miał najbardziej bezpośredni wpływ na przychody. Zmniejszenie tarcia w procesie zakupu jest równie cenne jak zmniejszenie czasów ładowania.

#6. Jak mierzyć efekt każdej optymalizacji

Wdrażając zmiany w fazach i mierząc po każdej z nich, mogłem określić dokładny wpływ każdej optymalizacji. To podejście oparte na danych zapobiega marnowaniu wysiłku i buduje jasną narrację dla interesariuszy.

#Ile trwa optymalizacja sklepu WooCommerce

#Jak zastosować te metody w WordPressie i WooCommerce w 2026

Trzy z opisanych metod zależą od funkcji WordPressa, WooCommerce i Cloudflare, które zmieniły się od czasu, gdy powstała większość poradników. Tak działa każda z nich według dokumentacji samych producentów.

#Jak generować obrazy AVIF w WordPressie

WordPress obsługuje AVIF od wersji 6.5, co ogłoszono na Make WordPress Core. Obsługa zależy od biblioteki graficznej na serwerze: WordPress współpracuje z Imagick i z GD, a sekcja o obsłudze mediów w informacjach o kondycji witryny pokazuje, czy AVIF jest dostępny. Do zamiany przesłanych plików JPEG na AVIF zespół core dokumentuje filtr image_editor_output_format. Filtr wp_editor_set_quality ustawia kompresję od 1 do 100 dla danego typu MIME. Według ogłoszenia AVIF jest domyślnie stratny z jakością 82, a jakość 100 przełącza go w tryb bezstratny.

wp media regenerate nie ma opcji formatu ani jakości. Jego opcje to identyfikatory załączników, --image_size, --skip-delete, --only-missing, --delete-unknown, --update-attachment-refs (tylko w wersjach nightly) i --yes (dokumentacja WP-CLI). Format i jakość ustalają filtry, a komenda odtwarza rozmiary obrazów, dlatego przykład z fazy 4 używa jednego i drugiego.

#Jak usunąć wygasłe transienty w WooCommerce

WP-CLI usuwa wygasłe transienty poleceniem wp transient delete --expired, a wp transient delete --all usuwa wszystkie (dokumentacja WP-CLI). Przy trwałym cache obiektów, takim jak Redis, transienty mogą trafiać do tego cache zamiast do tabeli wp_options, a podręcznik Transients API ostrzega, że kod nigdy nie powinien zakładać, że transient jest w bazie danych. Funkcja core delete_expired_transients(), dodana w WordPressie 4.9, nic nie robi, gdy działa zewnętrzny cache obiektów. Wygasłe wiersze zapisane przed włączeniem cache obiektów zostają więc w tabeli, dopóki coś nie usunie ich bezpośrednio z bazy. Tę pracę wykonała faza 3.

#Które strony i ciasteczka WooCommerce wyłączyć z cache

Dokumentacja deweloperska WooCommerce każe wyłączyć z cache stron koszyk, konto klienta i kasę, bo pokazują informacje o bieżącym kliencie i jego koszyku. Wymienia też ciasteczka, które cache może pomijać: woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed i store_notice[notice id]. Reguły LiteSpeed z fazy 2 wyłączają wszystkie trzy strony, a przykład Cloudflare z fazy 7 pokazuje koszyk i kasę.

Cloudflare zastępuje Page Rules zestawem osobnych produktów Rules i automatycznie migruje istniejące Page Rules (przewodnik migracji). Nowa konfiguracja wyraża tę samą logikę przez Cache Rules: ustawienie kwalifikacji do cache na kwalifikujące się zastępuje Cache Everything, ustawienia Edge TTL i Browser TTL przejmują wartości TTL, a reguła dopasowana do ciasteczka z kwalifikacją ustawioną na bypass trzyma odwiedzających z aktywną sesją koszyka poza wspólnym cache.

#Wstępny audyt wydajności WooCommerce

Jeśli Twój sklep uzyskuje wynik poniżej 70 w PageSpeed Insights, tracisz klientów każdego dnia. Moja usługa optymalizacji WooCommerce stosuje tę samą sprawdzoną metodologię opisaną w tym studium przypadku, dostosowaną do Twojego konkretnego sklepu i infrastruktury. Stoi za nią doświadczony programista WooCommerce, który prowadzi pełen proces od audytu po wdrożenie.

Oferuję bezpłatny wstępny audyt wydajności - szczegółowy raport pokazujący dokładnie, gdzie Twój sklep traci szybkość i ile przychodów Cię to kosztuje. Bez zobowiązań, bez nachalnej sprzedaży, tylko dane.

Skontaktuj się z WPPoland, aby umówić się na audyt, lub dowiedz się więcej o moich usługach optymalizacji szybkości WordPress.

#Powiązane zasoby

• Osiąganie 100/100 Core Web Vitals dla WordPress w 2026
• Przewodnik optymalizacji wydajności WooCommerce
• Usługi optymalizacji szybkości WordPress