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

#Problem

Europejski dystrybutor B2B operujący na platformie WooCommerce z katalogiem obejmującym ponad 12 000 produktów (SKU) i 4 rynkami językowymi mierzył się z krytycznymi problemami wydajnościowymi. Z powodu restrykcyjnej umowy o poufności (NDA) nazwa klienta pozostaje anonimowa, lecz przedstawione parametry techniczne i pomiary są w pełni rzeczywiste.

Przed rozpoczęciem optymalizacji sklep odnotowywał wysoki wskaźnik porzucania koszyków na etapie finalizacji zamówienia (42%). Czas ładowania kasy regularnie przekraczał 3 sekundy, a parametr TTFB wynosił 2,1 s. Wynikało to ze skomplikowanych obliczeń rabatów i cen kontraktowych pobieranych w czasie rzeczywistym z zewnętrznego systemu ERP przez API, które nakładały się na opóźnienia samej platformy.

Szczegółowy audyt techniczny wykazał trzy główne wąskie gardła:

1. Przeciążenie bazy danych: tabela wp_options rozrosła się do rozmiaru 2,1 GB i zawierała ponad 450 000 rekordów ładowanych przy każdym żądaniu (autoload=yes), co dodawało ponad 1,2 s narzutu zanim proces PHP w ogóle przystąpił do renderowania widoku.
2. Blokowanie wątku głównego przeglądarki: zewnętrzne skrypty analityczne i piksele marketingowe ładowane synchronicznie blokowały przeglądarkę klienta na ponad 1200 ms, spychając wskaźnik Largest Contentful Paint (LCP) do czerwonej strefy (5,4 s).
3. Niewydajny mechanizm koszyka AJAX: każde przejście między podstronami generowało niebuforowane wywołanie wc-ajax=get_refreshed_fragments, co pod realnym ruchem wysycało pulę procesów PHP-FPM i prowadziło do błędów połączenia (timeouts).

#Co zrobiłem

Aby trwale wyeliminować opóźnienia bez zaburzania transakcji i integracji z ERP, wdrożyłem całościowy plan naprawczy:

graph TD
    A[Strona WooCommerce przed optymalizacją] --> B[Optymalizacja bazy danych]
    A --> C[Odciążenie sesji i koszyka]
    A --> D[Przeniesienie skryptów zewnętrznych]
    
    B --> B1[Usunięcie 450k+ wierszy autoload]
    B --> B2[Wdrożenie Redis Object Cache]
    
    C --> C1[Wyłączenie odpytywania get_refreshed_fragments]
    C --> C2[Lokalne buforowanie stanu koszyka]
    
    D --> D1[Migracja analityki do Cloudflare Zaraz]
    D --> D2[Skrócenie blokowania wątku do 180 ms]

1. Gruntowne czyszczenie bazy danych: usunąłem z tabeli wp_options ponad 450 000 wygasłych transientów oraz osieroconych wpisów po odinstalowanych wtyczkach. Pulę kluczy ładowanych automatycznie zmniejszyłem do poniżej 1200 rekordów, redukując fizyczny rozmiar tabeli z 2,1 GB do poniżej 8 MB.
2. Konfiguracja pamięci podręcznej obiektów (Redis Object Cache): wdrożyłem Redis do buforowania transientów i powtarzalnych zapytań SQL, z precyzyjnym wykluczeniem grup cache powiązanych z sesjami klientów i ścieżką zakupową checkoutu.
3. Przeniesienie analityki na brzeg sieci przez Cloudflare Zaraz: zrezygnowałem z tradycyjnego ładowania tagów w przeglądarce użytkownika na rzecz przetwarzania server-side w Cloudflare Zaraz. Skrypty śledzące przestały rywalizować o zasoby procesora na urządzeniach mobilnych klientów.
4. Optymalizacja mechanizmu koszyka AJAX: wyłączyłem domyślne odpytywanie get_refreshed_fragments i zastąpiłem je mechanizmem synchronizacji bazującym na pamięci sessionStorage, aktualizującym stan koszyka wyłącznie w momencie realnego dodania produktu.

#Wynik

Optymalizacja przyniosła natychmiastowe odciążenie serwera oraz wyraźną poprawę wskaźników Core Web Vitals i konwersji, zweryfikowaną po 30 dniach od wdrożenia na produkcji:

Całkowicie zniknęły błędy timeoutów PHP-FPM przy wzmożonym ruchu B2B, a proces składania zamówienia z kalkulacją cen ERP zyskał pełną stabilność.

#Stack i czas

• Stack technologiczny: WordPress, WooCommerce, Redis Object Cache, Cloudflare Zaraz, PHP-FPM, MySQL, WP-CLI.
• Czas realizacji: 4 tygodnie prac analitycznych, czyszczenia bazy danych, wdrożenia konfiguracji i testów obciążeniowych na kopii produkcyjnej. Dane biznesowe i metryki wydajnościowe potwierdzone w 30-dniowym oknie ewaluacyjnym.