WooCommerce z tysiącami wariantów: optymalizacja strony produktu, bazy danych i koszyka

Produkty z kilkoma rozmiarami i kolorami zazwyczaj nie sprawiają WooCommerce większego problemu. Sytuacja zmienia się, gdy pojedynczy produkt ma setki kombinacji albo cały katalog obejmuje tysiące wariantów z osobnymi cenami, stanami magazynowymi, numerami SKU i zdjęciami. Wtedy spowolnienie może pojawić się zarówno podczas otwierania strony produktu, jak i przy wybieraniu opcji, dodawaniu towaru do koszyka czy przeliczaniu zamówienia.

Rozwiązaniem nie jest jedna wtyczka przyspieszająca. Skuteczna optymalizacja WooCommerce wymaga ustalenia, ile danych generuje produkt, które zapytania obciążają bazę oraz jakie skrypty wykonują się w przeglądarce. Dopiero na tej podstawie można zdecydować, czy ograniczyć liczbę kombinacji, wdrożyć obsługę AJAX, zmienić sposób prezentowania konfiguracji lub zoptymalizować warstwę danych.

Dlaczego duża liczba wariantów obciąża WooCommerce?

Wariant nie jest wyłącznie etykietą widoczną w selektorze. Może mieć własną cenę, dostępność, stan magazynowy, wagę, wymiary, obraz, SKU i zestaw metadanych dodanych przez rozszerzenia. Podczas przygotowania strony WooCommerce musi odnaleźć warianty produktu, zweryfikować ich widoczność i dostępność, a następnie przekazać informacje potrzebne do obsługi formularza zakupu.

Szczególnie kosztowne jest pobieranie pełnych tablic danych wariantów. Metoda odpowiedzialna za ich przygotowanie może dla każdej kombinacji wykonywać między innymi obliczenia cen, formatowanie dostępności i wymiarów oraz operacje związane z obrazami. Im więcej wariantów, tym większy koszt po stronie PHP, bazy danych i przeglądarki.

Problem może być dodatkowo wzmacniany przez wtyczki do cen zależnych od roli, wielowalutowości, stanów magazynowych, galerii, personalizacji czy integracji z systemem ERP. Jeżeli każda z nich wykonuje własną logikę dla wszystkich wariantów, liczba operacji rośnie szybciej niż sam katalog.

Audyt wąskich gardeł na stronie produktu

Optymalizację należy rozpocząć od pomiaru na kopii testowej sklepu. Analiza wyłącznie strony głównej nie wystarczy. Trzeba sprawdzić przynajmniej produkt prosty, produkt z kilkunastoma wariantami oraz najbardziej rozbudowany produkt w katalogu.

Zapytania SQL i czas generowania PHP

Query Monitor pozwala sprawdzić liczbę zapytań, ich czas, duplikaty oraz komponent, który je wywołał. Warto zwrócić uwagę na wielokrotnie powtarzane odczyty metadanych, zapytania wykonywane osobno dla każdego wariantu i operacje uruchamiane przez rozszerzenia niezwiązane bezpośrednio z formularzem zakupu.

Sama liczba zapytań nie rozstrzyga jeszcze o problemie. Jedno źle dopasowane zapytanie przeszukujące dużą tabelę może być droższe niż wiele szybkich odczytów z pamięci podręcznej. Dlatego należy analizować jednocześnie czas wykonania, powtarzalność i plan zapytania.

Rozmiar HTML i danych wariantów

W narzędziach deweloperskich przeglądarki należy sprawdzić rozmiar dokumentu oraz kod formularza wariantowego. Jeżeli informacje o setkach kombinacji są osadzane w stronie, rośnie ilość przesyłanych danych i czas potrzebny na ich przetworzenie przez JavaScript.

Trzeba też przetestować sam selektor: zmianę pierwszego atrybutu, wybór kompletnej kombinacji, aktualizację ceny, podmianę zdjęcia oraz aktywację przycisku dodania do koszyka. Opóźnienie może wynikać nie tylko z odpowiedzi serwera, ale także z ciężkiego skryptu, rozbudowanego DOM lub mechanizmu próbek kolorystycznych generującego setki elementów.

Ograniczenie ładowanych wariantów i obsługa AJAX

WooCommerce stosuje próg, powyżej którego nie przekazuje pełnego zestawu danych wszystkich wariantów bezpośrednio do strony. W aktualnej dokumentacji standardowy próg opisano jako 30 kombinacji. Dla większych produktów dopasowanie wybranego wariantu może odbywać się na żądanie, co ogranicza rozmiar początkowego dokumentu.

Podnoszenie tego progu za pomocą filtra nie powinno być traktowane jako uniwersalna naprawa selektora. Może poprawić sposób ukrywania niedostępnych opcji, ale jednocześnie zwiększyć ilość danych generowanych przed wyświetleniem strony. Przy setkach wariantów efekt bywa odwrotny do zamierzonego.

W rozbudowanych katalogach lepsze rezultaty może dać:

• pobieranie szczegółów dopiero po wybraniu kompletu atrybutów,
• ładowanie dostępnych wartości kolejnego pola na podstawie wcześniejszego wyboru,
• zwracanie przez endpoint tylko ceny, dostępności, identyfikatora i potrzebnego obrazu,
• podział bardzo rozbudowanego produktu na kilka logicznych produktów,
• zastąpienie wariantów dodatkami produktowymi, jeśli dana opcja nie wymaga osobnego SKU ani własnego stanu.

Endpoint AJAX powinien walidować dane i korzystać z API WooCommerce zamiast odczytywać przypadkowe rekordy bezpośrednio z tabel. Odpowiedź musi być możliwie mała, a szybko zmieniane informacje, takie jak stan magazynowy, nie powinny być przechowywane w długim cache bez prawidłowej invalidacji.

Optymalizacja bazy danych WooCommerce

Duży katalog wariantów szybko powiększa tabele przechowujące produkty i ich metadane. Nie oznacza to jednak, że należy od razu dodawać przypadkowe indeksy lub usuwać rekordy na podstawie samej nazwy. Każda operacja powinna zostać poprzedzona kopią zapasową i testem na środowisku stagingowym.

Indeksy dopasowane do realnych zapytań

Indeks ma sens wtedy, gdy odpowiada zapytaniu, które rzeczywiście spowalnia sklep. Plan wykonania można zweryfikować za pomocą polecenia EXPLAIN oraz monitoringu bazy. Dodatkowe indeksy zajmują miejsce i zwiększają koszt zapisu, dlatego nie powinny być instalowane hurtowo według uniwersalnej listy znalezionej w internecie.

Transients i trwały object cache

Transients przechowują tymczasowe wyniki obliczeń. Bez trwałego object cache ich dane mogą trafiać do bazy, natomiast przy poprawnie skonfigurowanym Redisie lub Memcached mogą być obsługiwane poza nią. W sklepie z wieloma wariantami object cache ogranicza powtarzanie tych samych odczytów w ramach kolejnych żądań, ale nie zastępuje optymalizacji źle napisanej wtyczki.

Nie należy automatycznie czyścić wszystkich transientów przy każdym wejściu administratora ani wykonywać pełnego czyszczenia według harmonogramu co kilka minut. Po takim zabiegu cache musi zostać odbudowany, co może chwilowo zwiększyć obciążenie.

Zbędne metadane

Warto odszukać metadane pozostawione przez usunięte integracje, stare importy i nieużywane galerie wariantów. Najpierw trzeba ustalić właściciela danego klucza i sprawdzić, czy nie jest nadal potrzebny podczas aktualizacji produktu, synchronizacji zapasów albo składania zamówienia. Bezpieczniejsza jest migracja według przygotowanego skryptu niż ręczne kasowanie rekordów w panelu bazy.

Cache katalogu, strony produktu i koszyka

Pełny cache strony dobrze sprawdza się w katalogu, kategoriach i na stronach produktów oglądanych przez anonimowych użytkowników. Warunkiem jest prawidłowe czyszczenie wpisu po zmianie ceny, dostępności, opisu lub zdjęcia.

Nie wolno natomiast serwować wspólnej wersji stron zawierających dane konkretnej sesji. Z pełnego cache należy wykluczyć koszyk, kasę i konto klienta, a także odpowiednie endpointy oraz żądania dodawania do koszyka. Konfiguracja CDN lub reverse proxy musi uwzględniać pliki cookie sesji WooCommerce.

Osobnej kontroli wymaga mini-koszyk. Mechanizm cart fragments wykorzystuje żądania AJAX do odświeżania jego zawartości. Jeżeli motyw umieszcza mini-koszyk na każdej podstronie, może generować dodatkowy ruch nawet tam, gdzie klient nie korzysta z funkcji zakupowych. Skrypt należy ładować tylko wtedy, gdy dany komponent jest faktycznie obecny i poprawnie przetestowany z cache strony.

Lżejsze zdjęcia i warunkowe skrypty WooCommerce

Przypisanie osobnego zdjęcia do każdego wariantu może znacząco zwiększyć transfer, zwłaszcza gdy wtyczka galerii próbuje pobrać wszystkie obrazy od razu. Na początku powinno zostać załadowane zdjęcie główne, a grafika konkretnego wariantu dopiero po dokonaniu wyboru.

• Generuj rozmiary odpowiadające faktycznemu miejscu w galerii.
• Stosuj nowoczesne formaty obrazów, jeśli infrastruktura sklepu obsługuje ich poprawne dostarczanie.
• Nie używaj pełnych plików źródłowych jako miniaturek próbek.
• Włącz leniwe ładowanie zdjęć poza pierwszym widokiem.
• Nie preloaduj galerii wszystkich wariantów.

Podobna zasada dotyczy JavaScriptu i CSS. Skrypty bramek płatniczych, rozbudowanych galerii, porównywarek lub formularzy wariantów powinny działać wyłącznie tam, gdzie są potrzebne. Warunkowe wyłączanie zasobów wymaga jednak testów zależności. Usunięcie pozornie zbędnego skryptu może przerwać aktualizację ceny albo obsługę koszyka.

Testy wydajności po wdrożeniu

Wynik należy porównać z pomiarem wykonanym przed zmianami, na tej samej infrastrukturze i dla tych samych scenariuszy. Test pojedynczego wejścia nie wystarczy, ponieważ pierwsze żądanie może odbudowywać cache.

Najważniejsze elementy kontroli to:

• TTFB – pokazuje, jak szybko serwer zaczyna odpowiadać; wzrost na rozbudowanym produkcie zwykle kieruje uwagę na PHP, bazę lub zewnętrzne integracje,
• INP – pomaga ocenić reakcję strony na wybór atrybutu, zmianę wariantu i kliknięcie przycisku koszyka,
• TBT w testach laboratoryjnych – ujawnia długie zadania JavaScript blokujące interakcję,
• liczba i czas zapytań SQL – wraz z informacją o duplikatach oraz ich źródle,
• rozmiar HTML i odpowiedzi AJAX – pozwala sprawdzić, czy ograniczono przesyłanie zbędnych danych,
• czas dodawania do koszyka i przeliczania – mierzony dla pustej oraz rozbudowanej sesji klienta.

Testy powinny obejmować użytkownika anonimowego i zalogowanego, urządzenie mobilne, pusty i wypełniony koszyk oraz kombinacje dostępne i niedostępne. Trzeba również sprawdzić aktualizację ceny, podatku, promocji, zdjęcia i stanu magazynowego.

Najważniejsza jest architektura produktu

WooCommerce może obsługiwać duże katalogi, ale produkt z tysiącami kombinacji nie zawsze powinien być pojedynczym produktem zmiennym. Jeżeli klient najpierw wybiera kolekcję, model lub materiał, podział oferty na kilka stron może uprościć selektor, zmniejszyć liczbę danych i ułatwić pozycjonowanie konkretnych grup produktów.

Najlepszy efekt daje połączenie rozsądnego modelu katalogu, wariantów pobieranych na żądanie, uporządkowanej bazy, trwałego object cache i warunkowo ładowanych zasobów. Optymalizacja kończy się dopiero wtedy, gdy pomiary potwierdzają szybsze działanie, a pełna ścieżka zakupowa nadal działa poprawnie.