Podsumowanie projektu
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 reprezentują rzeczywiste rezultaty uzyskane w ramach naszych prac optymalizacyjnych.
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.
1. Stan początkowy i ryzyka biznesowe
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.
2. Diagnoza techniczna
Nasz audyt wydajnościowy wykazał trzy główne wąskie gardła:
Przepełnienie tabeli opcji (Option Bloat)
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.
Blokowanie wątku głównego przez zewnętrzne skrypty
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.
Niebuforowane zapytania AJAX i zalew transientów
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).
3. Architektura i wdrożone rozwiązania
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[Oszczędność 800ms Wątku Głównego]Higiena bazy danych
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.
Przeniesienie pikseli śledzących na Edge
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 dało zysk 800 ms czasu procesora.
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.
4. Uzyskane rezultaty
Wyniki zmierzone po 30 dniach od wdrożenia:
| Metryka | Przed optymalizacją | Po optymalizacji | Różnica |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 5,4 sekundy | 1,8 sekundy | -66% (Zielona strefa) |
| TTFB Strony Kasy | 2,1 sekundy | 0,4 sekundy | -80% |
| Czas blokowania wątku głównego | 1200 ms | 180 ms | -85% |
| Porzucenie koszyków w procesie kasy | 42% | 34% | -19% |
5. Cenna lekcja dla inżynierów
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.