Z 40 na 98 PageSpeed: Jak Zoptymalizowaliśmy Sklep WooCommerce

Każda sekunda ma znaczenie w e-commerce. Badania konsekwentnie pokazują, że jednosekundowe opóźnienie w ładowaniu strony może zmniejszyć konwersje o 7 procent. 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 nasz zespół w WPPoland przekształcił 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.

---

#Klient: europejski sklep meblowy e-commerce

Nasz klient prowadzi średniej wielkości sklep meblowy online obsługujący klientów w Europie Środkowej i Zachodniej. Z katalogiem ponad 3500 produktów, 12 000 zdjęć produktów i średnią wartością zamówienia przekraczającą 420 EUR, 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ę.

---

#Wyzwanie: śmierć od tysiąca wtyczek

Kiedy po raz pierwszy przeprowadziliśmy audyt strony, znaleźliśmy 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ą

Metryka	Wartość	Ocena
Wynik PageSpeed (Mobile)	40	Słaby
Largest Contentful Paint (LCP)	8,2s	Słaby
Interaction to Next Paint (INP)	680ms	Słaby
Cumulative Layout Shift (CLS)	0,35	Słaby
Współczynnik konwersji	2,3%	Poniżej średniej
Współczynnik odrzuceń	68%	Krytyczny
Time to First Byte (TTFB)	2,4s	Słaby
Całkowita waga strony	6,8 MB	Nadmierna

---

#Nasze podejście: 7-fazowa metodologia optymalizacji

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

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

Zanim dotknęliśmy pojedynczej linii kodu, spędziliśmy 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. Zmigrowaliśmy 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 ^/my-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. Przeprowadziliśmy 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)

Pipeline przetwarzania obrazów został zautomatyzowany przy użyciu niestandardowej komendy WP-CLI:

wp media regenerate --image_size=all --format=avif --quality=75

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. Skategoryzowaliśmy każdy skrypt na stronie:

Kategoria	Skrypty	Działanie
Krytyczne (kasa, koszyk)	4	Zachowane, zoptymalizowane
Analityka i śledzenie	3	Przeniesione do Web Worker
Nieużywane skrypty wtyczek	14	Całkowicie usunięte
Ulepszenia UI	6	Odroczone, warunkówo ładowane

Dla skryptów analitycznych wdrożyliśmy 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 });
});

Wyeliminowaliśmy 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. Przeprojektowaliśmy 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 niestandardówymi 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.

---

#Wyniki: metryki po optymalizacji

Po czterech tygodniach systematycznej optymalizacji transformacja była dramatyczna:

Metryka	Przed	Po	Poprawa
Wynik PageSpeed (Mobile)	40	98	+145%
Largest Contentful Paint (LCP)	8,2s	0,8s	-90%
Interaction to Next Paint (INP)	680ms	45ms	-93%
Cumulative Layout Shift (CLS)	0,35	0,02	-94%
Współczynnik konwersji	2,3%	4,8%	+108%
Współczynnik odrzuceń	68%	34%	-50%
Time to First Byte (TTFB)	2,4s	0,09s	-96%
Całkowita waga strony	6,8 MB	1,1 MB	-84%

---

#Wpływ biznesowy: liczby, które się liczą

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

• +108% wzrost współczynnika konwersji - z 2,3% do 4,8%
• +156% przychodów z urządzeń mobilnych - użytkownicy mobilni mogli wreszcie robić zakupy bez frustracji
• -52% redukcja współczynnika odrzuceń - odwiedzający zostawali i przeglądali zamiast wychodzić
• ROI osiągnięte w 6 tygodni - projekt optymalizacji zwrócił się w niecałe dwa miesiące
• +23% średnia wartość zamówienia - szybsze przeglądanie produktów prowadziło do większej liczby produktów w koszyku
• +41% ruchu organicznego - poprawione Core Web Vitals przyczyniły się do lepszych pozycji w wyszukiwarce w ciągu 8 tygodni

Klient oszacował, że roczny wzrost przychodów przypisywany optymalizacji przekroczył 380 000 EUR, przy koszcie projektu stanowiącym ułamek tej kwoty.

---

#Wyciągnięte wnioski

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

#1. Infrastruktura serwerowa to fundament

Ż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. Higiena bazy danych jest obowiązkowa

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. Mniej wtyczek, szybszy sklep

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. Obrazy to najłatwiejszy zysk

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. UX kasy to dźwignia przychodów

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. Mierz wszystko w izolacji

Wdrażając zmiany w fazach i mierząc po każdej z nich, mogliśmy 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.

---

#Podsumowanie harmonogramu

Tydzień	Faza	Kluczowe działania
Tydzień 1	Audyt + Serwer	Pełny audyt techniczny, migracja serwera, konfiguracja Redis
Tydzień 2	Baza danych + Obrazy	Czyszczenie transientów, optymalizacja zapytań, konwersja AVIF
Tydzień 3	JavaScript + Kasa	Usunięcie wtyczek, odroczenie skryptów, redesign kasy
Tydzień 4	CDN + QA	Konfiguracja Cloudflare, edge caching, kompleksowe testy

---

#Czy Twój sklep WooCommerce traci pieńiądze?

Jeśli Twój sklep uzyskuje wynik poniżej 70 w PageSpeed Insights, tracisz klientów każdego dnia. Nasza usługa optymalizacji WooCommerce stosuje tę samą sprawdzoną metodologię opisaną w tym studium przypadku, dostosowaną do Twojego konkretnego sklepu i infrastruktury.

Oferujemy 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 naszych 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