Anonimowe studium przypadku

Poufne odzyskanie wydajności WooCommerce

To anonimowe odzyskanie WooCommerce B2B w UE (ponad 12 000 SKU) naprawiło wolny koszyk na telefonach bez przebudowy. Klienta nie nazwę; poniższe poprawki i metryki są prawdziwe.

Punkt startowy

Sklep miał typowy kształt WooCommerce: działający katalog, finalizację zakupu, której nie wolno było zepsuć, kilka skryptów marketingowych, motyw z latami nadpisywań i czerwone Core Web Vitals na kluczowych szablonach mobilnych.

Ryzyko biznesowe było konkretne. Każda optymalizacja dotykająca koszyka, płatności, stanów magazynowych, podatków albo sesji musiała mieć środowisko testowe, pomiar i plan powrotu.

Diagnoza

Pierwszy krok to rozdzielenie rodzin szablonów: strona główna, kategoria, produkt, koszyk, finalizacja zakupu i treści. Każda rodzina miała inne ograniczenia, więc jeden wynik dla całej strony ukrywałby prawdziwe problemy.

Największe koszty to suma: skrypty zewnętrzne za wcześnie, nieużywany CSS, rozjechane obrazy, chybione cache oraz niecache'owane wc-ajax=get_refreshed_fragments na każdym ładowaniu, które pod obciążeniem zalewało PHP-FPM.

Decyzja architektoniczna

Projekt nie zaczął się od przepisywania wszystkiego. Pierwsza decyzja: chronić finalizację zakupu, a dopiero potem przesuwać bezpieczne powierzchnie w stronę sprawniejszej pamięci podręcznej i lżejszego renderowania.

Cloudflare obsługiwał reguły na brzegu sieci, zasady pamięci podręcznej, przekierowania, filtrowanie botów i obserwowalność. WordPress i WooCommerce zostały źródłem prawdy dla handlu. Zmiany frontendowe były planowane dla każdej rodziny szablonów, nie jako ogólne hasło 'czyszczenia motywu'.

Model dowożenia

Prace szły krótkimi partiami: pomiar bazowy, audyt skryptów, obrazy i układ strony, polityka pamięci podręcznej, izolacja finalizacji zakupu, walidacja na środowisku testowym, wdrożenie produkcyjne i pomiar po wdrożeniu.

Każda partia miała ścieżkę powrotu. To ważniejsze niż efektowne wdrożenie, gdy przychód przechodzi przez tę samą finalizację zakupu, która jest optymalizowana.

Przedziały wyników

Pomiar 30 dni po wdrożeniu w poufnym sklepie B2B UE: LCP 5,4 s do 1,8 s (-66%), TTFB finalizacji zakupu 2,1 s do 0,4 s (-80%), blokada głównego wątku 1200 ms do 180 ms (-85%), porzucenie między koszykiem a finalizacją zakupu 42% do 34% (-19%).

Lekcja: odzyskiwanie wydajności WooCommerce nie polega na gonieniu idealnego wyniku, tylko na dobrym ustawieniu granicy między stronami komercyjnymi możliwymi do cacheowania a żywymi przepływami transakcyjnymi.

Pobierz diagnostykę opóźnień checkoutu

Użyj tego samego arkusza pomiarów co w diagnozie powyżej. Wiersze referencyjne powtarzają opublikowane anonimowe metryki; puste wiersze są na pomiar bazowy Twojego sklepu.

Najczęściej zadawane pytania

Jak naprawić wolny koszyk WooCommerce na telefonach bez przebudowy sklepu?

Zaczynaj od pomiaru koszyka, finalizacji i kart produktu, nie od przepisania. W poufnym sklepie B2B UE (ponad 12 000 SKU) naprawiliśmy wolny koszyk mobilny przez usunięcie ponad 450 000 wierszy autoload w wp_options, wyłączenie wc-ajax=get_refreshed_fragments na każdym ładowaniu, przeniesienie ponad 25 pikseli na Cloudflare Zaraz i Redis z wykluczeniem grup finalizacji zakupu. TTFB finalizacji zakupu spadł z 2,1 s do 0,4 s, LCP z 5,4 s do 1,8 s; każda partia miała środowisko testowe i plan powrotu przy dryfie płatności.

Co powoduje wolne fragmenty koszyka WooCommerce przy dużym ruchu?

Domyślny mini-koszyk odpala niecache'owane wc-ajax=get_refreshed_fragments na każdym ładowaniu. Przy współbieżnym ruchu te AJAX-y zalewają pulę PHP-FPM, kolejkują połączenia do bazy i dodają opóźnienie, zanim klient wejdzie w finalizację zakupu. Tu doszło do tego wp_options o rozmiarze 2,1 GB (ponad 450 000 autoload). Poprawka: wyłącz automatyczne odświeżanie fragmentów, aktualizuj koszyk dopiero po add-to-cart (u nas sessionStorage) i wyczyść autoload.

Jak skrócić opóźnienie finalizacji zakupu WooCommerce bez psucia płatności?

Traktuj finalizację zakupu jako niecache'owalną i izoluj ją przed tuningiem katalogu. Redis na transienty i wyniki zapytań, ale bez grup sesji i finalizacji zakupu, żeby podatki, stany i ceny ERP zostały dokładne. Skrypty marketingowe przenieś na edge (Cloudflare Zaraz). Wdrażaj małymi partiami ze środowiskiem testowym i planem powrotu; nigdy nie cache'uj stron z cookie sesji. Wynik: TTFB finalizacji zakupu 2,1 s do 0,4 s przy stabilnych płatnościach B2B.

Dlaczego klient nie jest nazwany?

Umowa nie pozwala publikować nazwy, screenshotów, danych o ruchu i części identyfikatorów handlowych. Mierzalne delty wydajności i metoda inżynierska są publiczne i opisane powyżej.

Chcesz taką diagnozę dla swojego sklepu?

Wyślij aktualny stos technologiczny, najwolniejsze szablony i ograniczenie biznesowe. Powiem, czy pierwszym ruchem powinno być odzyskanie wydajności, migracja headless, czy mniejszy audyt.

Zamów audyt techniczny