Optymalizacja Wydajności WooCommerce i Core Web Vitals (Case Study)

#Jak przyspieszyć wolny sklep WooCommerce B2B z 12 000 produktów

Niniejsze studium przypadku (case study) opisuje optymalizację wydajności sklepu internetowego B2B opartego na WooCommerce, należącego do europejskiego dystrybutora z katalogiem obejmującym ponad 12 000 produktów (SKU). Ze względu na restrykcyjne umowy o poufności (NDA), tożsamość klienta pozostaje anonimowa, jednak wdrożone rozwiązania techniczne i uzyskane metryki są rzeczywiste.

Przed rozpoczęciem prac klient mierzył się z wysokim współczynnikiem porzucania koszyków na etapie finalizacji zamówienia. Było to bezpośrednio spowodowane dużymi opóźnieniami w działaniu serwera pod obciążeniem, słabymi wskaźnikami Core Web Vitals (LCP w czerwonej strefie) oraz blokowaniem tabel bazy danych.

#Dlaczego wolny checkout z cenami z ERP kosztuje zamówienia B2B

Sklep B2B klienta funkcjonował w oparciu o następujące parametry:

• Rozmiar katalogu: ponad 12 000 aktywnych produktów z rozbudowanymi wariantami.
• Wersje językowe: 4 aktywne rynki europejskie obsługiwane przez wielojęzyczne translacje.
• Ryzyko biznesowe: Każda sekunda opóźnienia ładowania strony skutkowała spadkiem współczynnika konwersji o około 7%. Podczas generowania faktur B2B, czas ładowania kasy regularnie przekraczał 3 sekundy.
• Ryzyko techniczne: Proces zamówienia zależał od obliczeń cen w czasie rzeczywistym pobieranych z systemu ERP przez zewnętrzne API REST. Wszelkie opóźnienia frontendu nakładały się na czas odpowiedzi API.

#Jak znaleźć wąskie gardła wolnego sklepu WooCommerce

Nasz audyt wydajnościowy wykazał trzy główne wąskie gardła:

#Jak 450 000 wierszy autoload w wp_options spowalnia każdą stronę

Tabela wp_options urosła do 2,1 GB, przechowując ponad 450 000 wierszy z flagą autoload ustawioną na yes. Przy każdym żądaniu serwer musiał załadować ten potężny zbiór danych do pamięci RAM, co dodawało ponad 1,2 sekundy czasu przetwarzania zanim PHP w ogóle zaczął generować układ strony.

#Jak piksele śledzące blokują wątek główny w sklepie WooCommerce

Ponad 25 pikseli śledzących i kodów analitycznych (Google Tag Manager, Meta, LinkedIn, Hotjar itp.) było ładowanych synchronicznie w przeglądarce klienta, blokując wątek główny na ponad 1200 ms i drastycznie zaniżając wskaźnik LCP.

#Dlaczego AJAX mini-koszyka zalewa pulę PHP-FPM pod obciążeniem

Witryna korzystała z wyskakujących koszyków, które przy każdym przejściu na podstronę wysyłały niebuforowane żądanie wc-ajax=get_refreshed_fragments. Pod dużym obciążeniem zapytania te wysycały pulę procesów PHP-FPM, powodując błędy połączenia z bazą danych (timeouts).

#Jak przyspieszyć WooCommerce bez ryzyka dla checkoutu

Aby wyeliminować opóźnienia bez ryzyka dla transakcji i integracji z ERP, wdrożyliśmy czterostopniową strategię optymalizacji:

graph TD
    A[Strona WooCommerce przed optymalizacją] --> B[Optymalizacja Bazy Danych]
    A --> C[Pamięć podręczna Edge i Odciążenie Sesji]
    A --> D[Przeniesienie Zewnętrznych Skryptów]
    
    B --> B1[Usunięcie 450k+ Autoloaded Rows]
    B --> B2[Integracja Redis Object Cache]
    
    C --> C1[Wyłączenie Fragment Refresh Ajax]
    C --> C2[Omijanie Cache przy Wykryciu Ciasteczka]
    
    D --> D1[Migracja Pikseli do Cloudflare Zaraz]
    D --> D2[Wątek główny 1200ms do 180ms]

#Jak zmniejszyć wp_options z 2,1 GB do poniżej 8 MB

Oczyściliśmy tabelę wp_options ze starych danych tymczasowych (transients) oraz pozostałości po dawno usuniętych wtyczkach. Pula opcji ładowanych automatycznie została zmniejszona do mniej niż 1200 kluczy. Rozmiar tabeli zmalał z 2,1 GB do poniżej 8 MB.

#Pamięć podręczna obiektów (Redis Object Cache)

Uruchomiliśmy klaster Redis do przechowywania transientów i wyników zapytań SQL. Grupy cache powiązane z sesjami klientów i kasą zostały wyłączone z buforowania trwałego, zapewniając pełne bezpieczeństwo i poprawność koszyków.

#Jak przenieść piksele marketingowe na edge przez Cloudflare Zaraz

Zrezygnowaliśmy z tradycyjnego Google Tag Managera uruchamianego w przeglądarce klienta na rzecz usługi Cloudflare Zaraz. Kody analityczne są teraz przetwarzane po stronie sieci Cloudflare (Server-Side), co odciążyło przeglądarki użytkowników i skróciło blokowanie wątku głównego z 1200 ms do 180 ms.

#Optymalizacja zapytań koszyka AJAX

Wyłączyliśmy domyślny skrypt WooCommerce odpowiedzialny za odświeżanie koszyka i zastąpiliśmy go autorskim mechanizmem bazującym na lokalnej pamięci przeglądarki (sessionStorage). Koszyk aktualizuje się teraz tylko w momencie dodania produktu, co wyeliminowało tysiące zbędnych zapytań do bazy danych.

#Jak zmieniły się LCP, TTFB i porzucenia koszyka po 30 dniach

Wyniki zmierzone po 30 dniach od wdrożenia:

#Co naprawić w dużym sklepie WooCommerce przed redesignem

W przypadku dużych platform e-commerce, wygląd witryny ma drugorzędne znaczenie dla wydajności. Prawdziwy zysk przynosi higiena bazy danych oraz odciążenie przeglądarki klienta. Przeniesienie skryptów śledzących do workerów edge (np. Cloudflare Zaraz) oraz zablokowanie automatycznych zapytań AJAX koszyka to najskuteczniejsze sposoby na uzyskanie świetnych wyników Core Web Vitals w sklepach o dużym katalogu produktów.