Produkt prosty otwiera się błyskawicznie, ale karta produktu z kilkudziesięcioma wariantami potrzebuje kilku sekund? Po kliknięciu koloru albo rozmiaru cena, zdjęcie i dostępność aktualizują się z wyraźnym opóźnieniem? Problemem bardzo często nie jest sam WooCommerce, lecz liczba kombinacji oraz ilość danych, które sklep musi przetworzyć dla każdego wariantu.
Wariant WooCommerce może mieć własną cenę, promocję, SKU, stan magazynowy, zdjęcie, wagę, wymiary, klasę wysyłkową i inne metadane. Jeżeli jeden produkt ma 10 wariantów, skala jest niewielka. Przy 200 czy 500 wariantach sytuacja wygląda już zupełnie inaczej.
Przy optymalizacji nie zaczynam więc od zwiększania limitów PHP. Najpierw ustalam, czy rzeczywiście potrzebuję tylu wariantów, co dokładnie ładuje frontend i czy dodatkowa wtyczka nie zmusza WooCommerce do pobierania znacznie większej ilości danych, niż jest potrzebna klientowi.
Liczba wariantów może rosnąć znacznie szybciej niż liczba atrybutów.
WooCommerce ma domyślny próg 30 wariantów wpływający na sposób działania selektorów.
Podniesienie progu AJAX nie jest automatyczną metodą przyspieszenia strony.
Swatche, galerie wariantów i page builder mogą dokładać własne operacje dla każdej kombinacji.
Wolny frontend i wolne zapisywanie produktu w panelu to dwa różne problemy.
Przy dużych katalogach sprawdzam również bazę danych, PHP, object cache i hosting.
Dlaczego liczba wariantów WooCommerce rośnie tak szybko?
Największy problem pojawia się wtedy, gdy kilka atrybutów zaczyna się ze sobą łączyć.
Załóżmy, że produkt ma:
10 kolorów
× 8 rozmiarów
× 5 materiałów
= 400 możliwych kombinacjiW panelu nadal widzę „tylko” trzy atrybuty. WooCommerce może jednak mieć do obsłużenia nawet kilkaset osobnych wariantów produktu.
Kolor, rozmiar, materiał.
Powstają dziesiątki lub setki wariantów.
Cena, stock, zdjęcie, SKU i pozostałe informacje.
Sklep musi dopasować kombinację wybraną przez klienta.
Dlatego przy bardzo rozbudowanych produktach pytam najpierw, czy każda możliwość naprawdę musi być osobnym wariantem.
Kiedy opcja powinna być wariantem, a kiedy zwykłym dodatkiem?
Wariant ma sens szczególnie wtedy, gdy konkretna kombinacja potrzebuje własnych danych.
Ma własny stan magazynowy, SKU, inną cenę albo inne parametry wysyłki.
Jeżeli nie potrzebuje osobnego stocku i SKU, być może lepiej obsłużyć ją jako dodatek produktu.
Jeżeli każda drobna opcja zostanie zbudowana jako atrybut wariacyjny, liczba kombinacji może eksplodować.
Czasem lepsza architektura to:
Wariant:
rozmiar + kolor
Dodatkowe opcje:
grawer
pakowanie prezentowe
tekst własny
dodatkowe akcesoriumDzięki temu klient nadal może skonfigurować produkt, ale WooCommerce nie musi przechowywać setek niepotrzebnych kombinacji wariantów.
1. Sprawdź, ile wariantów ma naprawdę wolny produkt
Nie zaczynam od optymalizacji całego sklepu. Wybieram jeden produkt, na którym problem jest łatwy do odtworzenia.
Porównuję przykładowo:
| Produkt | Liczba wariantów | Zachowanie |
|---|---|---|
| Produkt A | 6 | Ładuje się szybko |
| Produkt B | 28 | Niewielkie opóźnienie |
| Produkt C | 160 | Karta produktu wyraźnie zwalnia |
| Produkt D | 450 | Duże opóźnienia lub problemy z wyborem |
Jeżeli czas odpowiedzi rośnie razem z liczbą wariantów, mam mocny punkt zaczepienia.
2. WooCommerce ma próg 30 wariantów – i nie bez powodu
WooCommerce zmienia zachowanie selektorów produktu w zależności od liczby dostępnych wariantów.
Domyślnie granicą jest:
30 wariantówPrzy mniejszej liczbie WooCommerce może dynamicznie zawężać dostępne opcje po wybraniu wcześniejszego atrybutu.
Przy większej liczbie zachowanie jest uproszczone, aby ograniczyć koszt obsługi ogromnej liczby kombinacji.
Przykładowo przy produkcie:
Rozmiar: M
Dostępne kolory:
Czarny
Białyponiżej progu WooCommerce może dynamicznie ograniczyć listę kolorów do dostępnych kombinacji.
Przy dużej liczbie wariantów lista może pozostać pełna, a dopiero po wybraniu nieistniejącej kombinacji klient otrzyma informację, że taki wariant nie jest dostępny.
3. Nie zwiększaj bezmyślnie woocommerce_ajax_variation_threshold
W internecie można znaleźć snippet w rodzaju:
add_filter(
'woocommerce_ajax_variation_threshold',
function( $threshold, $product ) {
return 500;
},
10,
2
);Taki kod może sprawić, że zachowanie małego produktu zostanie zachowane również przy setkach wariantów.
Problem w tym, że właśnie z powodów wydajnościowych WooCommerce ustawia znacznie niższy próg.
Przy setkach wariantów może oznaczać więcej danych i więcej pracy podczas generowania strony produktu. Zmieniam ten próg dopiero po pomiarach, a nie dlatego, że pierwszy snippet w Google ustawia go na 500.
Czasem sens ma nawet niższy próg
Jeśli konkretny produkt ma ciężkie warianty, dodatkowe zdjęcia albo dużo logiki wykonywanej przez rozszerzenia, mogę testowo obniżyć próg tylko dla tego produktu.
add_filter(
'woocommerce_ajax_variation_threshold',
'szn_variation_threshold',
10,
2
);
function szn_variation_threshold( $threshold, $product ) {
if ( $product && 123 === $product->get_id() ) {
return 20;
}
return $threshold;
}
123 jest tutaj wyłącznie przykładowym ID produktu.
Taką zmianę testuję pod kątem zarówno czasu ładowania, jak i UX wyboru wariantu.
4. Sprawdź, ile danych trafia do HTML karty produktu
Przy produkcie wariantowym warto zajrzeć do źródła strony albo DevTools i sprawdzić element formularza wariantów.
W określonych konfiguracjach można znaleźć dane związane z dostępnymi wariantami, np.:
variation_id
attributes
display_price
display_regular_price
image
availability_html
dimensions
weight
skuIm więcej wariantów i im bogatsze dane każdego z nich, tym większa ilość informacji do przygotowania, przesłania i przetworzenia.
Jeśli strona produktu ma kilka megabajtów HTML jeszcze przed pobraniem zdjęć, jest to wyraźny sygnał, że warto sprawdzić sposób generowania wariantów.
5. Variation Swatches mogą poprawić UX, ale pogorszyć wydajność
Kolorowe próbki zamiast klasycznych selectów często wyglądają znacznie lepiej:
● czarny
● biały
● zielony
zamiast:
[ Wybierz kolor ▼ ]Problem pojawia się wtedy, gdy wtyczka swatches dla każdego wariantu próbuje pobrać dodatkowo:
- obrazek,
- cenę,
- stan magazynowy,
- miniaturę atrybutu,
- dodatkowe HTML,
- niestandardowe metadane.
Dlatego przy wolnym produkcie robię prosty test: chwilowo wyłączam rozszerzenie swatches na kopii lub stagingu i porównuję czas generowania strony.
Jeśli produkt nagle przyspiesza kilkukrotnie, nie szukam już problemu w samym hostingu.
6. Page builder może wymuszać dodatkowe pobieranie danych wariantów
Karta produktu zbudowana przez Elementor, motyw premium albo blokowy template może mieć kilka niezależnych elementów korzystających z danych produktu.
Przykładowo osobne moduły mogą potrzebować:
- ceny wariantu,
- SKU,
- galerii,
- stanu magazynowego,
- wymiarów,
- opisu wariantu.
Jeżeli każdy element osobno wykonuje kosztowne operacje dla wszystkich wariantów, liczba zapytań i czas PHP mogą szybko wzrosnąć.
Dlatego porównuję niestandardowy template z możliwie prostą kartą produktu WooCommerce. Jeśli różnica jest duża, szukam konkretnego widgetu lub dodatku, który ją powoduje.
7. Zdjęcie dla każdego wariantu może ważyć więcej niż same dane produktu
Produkt z 80 kolorami może mieć 80 osobnych zdjęć. Jeśli dodatkowo każdy wariant posiada rozbudowaną galerię, skala szybko rośnie.
Sprawdzam więc:
- format WebP lub AVIF tam, gdzie ma to sens,
- wymiary plików przesyłanych do WordPressa,
- rozmiar miniatur wykorzystywanych na karcie produktu,
- lazy loading galerii,
- czy wtyczka nie pobiera wszystkich pełnych zdjęć od razu,
- czy CDN prawidłowo obsługuje media.
Nie ma sensu oszczędzić 200 ms na zapytaniach PHP, jeśli w tym samym czasie przeglądarka pobiera kilkadziesiąt megabajtów zdjęć wariantów.
8. Nie generuj kombinacji, których nigdy nie sprzedajesz
Załóżmy, że produkt ma:
Kolory:
10
Rozmiary:
10
Teoretycznie:
100 wariantówAle w rzeczywistości tylko 37 kombinacji jest dostępnych.
Nie widzę powodu, żeby tworzyć pozostałe 63 jako osobne, nieużywane warianty tylko dlatego, że można wygenerować wszystkie kombinacje jednym przyciskiem.
Im mniej niepotrzebnych rekordów wariantów, tym prostsze zarządzanie:
- stanami magazynowymi,
- cenami,
- zdjęciami,
- importami,
- synchronizacją z ERP,
- frontendem produktu.
9. Uważaj na duplikaty i warianty typu „Dowolny…”
Warianty mogą korzystać z wartości:
Dowolny kolor
Dowolny rozmiarJest to przydatne w określonych konfiguracjach, ale przy rozbudowanym produkcie łatwo stworzyć reguły nakładające się na bardziej szczegółowe warianty.
Jeśli produkt ma dziesiątki podobnych albo zdublowanych kombinacji, utrudnia to nie tylko wydajność, ale również poprawne dopasowanie:
- ceny,
- stocku,
- wysyłki,
- SKU,
- obrazu wariantu.
Przy dużych produktach najpierw porządkuję strukturę, a dopiero później szukam optymalizacji serwerowej.
10. Wolne warianty w panelu administratora to osobny problem
Czasami frontend działa dobrze, ale wejście w zakładkę „Warianty” trwa kilkanaście sekund.
Albo jeszcze gorzej:
zmieniam ceny
↓
klikam Zapisz
↓
część zmian znikaW takim przypadku sprawdzam już inne elementy:
- PHP memory_limit,
- max_execution_time,
- max_input_vars,
- mod_security,
- logi PHP,
- wydajność bazy.
max_input_vars jest szczególnie ważny przy dużych formularzach
PHP ogranicza liczbę wartości, które może przyjąć w jednym formularzu.
Jeśli produkt z dużą liczbą wariantów generuje tysiące pól, zbyt niski limit może spowodować, że część danych podczas zapisywania zostanie ucięta.
Aktualną wartość sprawdzam m.in. w:
WooCommerce
→ Status
→ Środowisko serwera
→ PHP max input varsNie zwiększam jednak wartości do absurdalnego poziomu bez diagnozy. Najpierw sprawdzam rzeczywistą liczbę danych i możliwości hostingu.
11. Cache strony nie rozwiąże każdego problemu z wariantami
Page cache może bardzo dobrze przyspieszyć statyczną część karty produktu.
Nie usuwa jednak automatycznie kosztu:
- dynamicznego wyboru wariantu,
- zapytania AJAX po konkretną kombinację,
- przetwarzania niestandardowych dodatków,
- operacji wykonywanych po stronie przeglądarki.
Dlatego przy wariantach mierzę zarówno:
czas odpowiedzi serwera
+
rozmiar HTML
+
liczbę żądań
+
czas JavaScript
+
czas wyboru wariantu12. Object cache może pomóc przy cięższym WooCommerce
Jeżeli sklep ma duży katalog produktów, dużo wariantów i wiele powtarzalnych zapytań do WordPressa, trwały object cache, np. Redis, może ograniczyć część pracy wykonywanej ponownie przy kolejnych żądaniach.
Nie traktuję go jednak jako lekarstwa na źle zaprojektowany produkt z tysiącem wariantów.
Cache nie zmienia faktu, że aplikacja nadal ma ogromną strukturę produktu do obsługi.
Najpierw ograniczam zbędną pracę, później przyspieszam to, co rzeczywiście musi zostać.
13. HPOS nie przyspieszy bezpośrednio wyboru wariantów
HPOS, czyli High-Performance Order Storage, jest bardzo ważną zmianą WooCommerce, ale dotyczy przede wszystkim danych zamówień.
Jeżeli problem wygląda tak:
otwieram produkt
↓
czekam 5 sekund
↓
wybieram kolor
↓
wariant długo się ładujesamo włączenie HPOS nie jest rozwiązaniem problemu struktury wariantów produktu.
W dużym sklepie HPOS nadal może być korzystny dla obsługi zamówień i checkoutu, ale nie zastępuje optymalizacji samego katalogu.
14. Aktualizacje WooCommerce i wtyczek też mają znaczenie
Mechanizmy produktów wariantowych są regularnie rozwijane i optymalizowane.
Na zaniedbanym sklepie mogę mieć jednocześnie:
- stare WooCommerce,
- nieaktualne Variation Swatches,
- przestarzały template produktu w motywie,
- starą wersję PHP,
- kod napisany kilka lat temu pod inną wersję WooCommerce.
Nie aktualizuję jednak wszystkiego bezpośrednio na produkcji. Najpierw robię backup albo kopię stagingową, aktualizuję komponenty i porównuję produkt przed oraz po zmianach.
15. Sprawdź, czy problemem rzeczywiście jest serwer
Słaby hosting może mocno pogorszyć sytuację, ale nie każdy problem z wariantami rozwiąże większy pakiet.
Jeżeli ten sam serwer ładuje:
produkt prosty: 0,5 s
produkt z 8 wariantami: 0,7 s
produkt z 300 wariantami: 6,5 snajpierw analizuję logikę produktu.
Jeśli natomiast nawet proste produkty mają wysoki TTFB, PHP regularnie dobija do limitów CPU, a baza odpowiada wolno, problem jest szerszy.
Wtedy oprócz produktów sprawdzam:
- CPU i RAM,
- PHP workers,
- MySQL,
- WP-Cron,
- Action Scheduler,
- ruch botów,
- cache,
- wolne zapytania.
Jak diagnozuję wolne warianty WooCommerce krok po kroku?
Wybieram jeden problematyczny produkt
Sprawdzam dokładną liczbę wariantów, atrybutów i rzeczywistych kombinacji.
Porównuję go z prostszym produktem
Dzięki temu widzę, czy czas odpowiedzi rośnie bezpośrednio razem z wariantami.
Sprawdzam frontend
Analizuję HTML, Network, żądania AJAX, JavaScript oraz wielkość zasobów.
Testuję swatche i dodatki produktowe
Na stagingu eliminuję rozszerzenia, które mogą pobierać dane wszystkich wariantów.
Porządkuję strukturę wariantów
Usuwam zbędne kombinacje i rozważam przeniesienie prostych opcji poza system wariantów.
Sprawdzam środowisko PHP i bazę
Szczególnie wtedy, gdy wolne jest również edytowanie albo zapisywanie produktu.
Testuję cache i object cache
Dopiero po ograniczeniu zbędnej pracy sprawdzam, jak dużo można zyskać dzięki cache.
Powtarzam pomiary
Porównuję czas produktu przed i po zmianach, zamiast oceniać efekt „na oko”.
Co mierzę przed i po optymalizacji?
| Element | Co sprawdzam? |
|---|---|
| TTFB | Jak długo serwer generuje pierwszą odpowiedź. |
| HTML | Czy karta produktu nie zawiera ogromnej ilości danych wariantów. |
| AJAX | Jak długo trwa pobranie danych po wyborze opcji. |
| JavaScript | Czy przeglądarka nie blokuje się podczas obsługi wariantów. |
| Zdjęcia | Ile danych pobiera galeria produktu. |
| Zapytania SQL | Czy produkt generuje wyjątkowo ciężkie lub powtarzalne zapytania. |
| UX | Jak szybko po kliknięciu klient widzi właściwą cenę i dostępność. |
Wolne warianty mogą bezpośrednio obniżać sprzedaż
Klient nie analizuje, czy problemem jest AJAX,
PHP czy tabela postmeta.
Widzi po prostu:
klikam rozmiar
↓
nic się nie dzieje
↓
klikam drugi raz
↓
spinner
↓
cena zmienia się po kilku sekundachPrzy wyborze produktu klient powinien natychmiast rozumieć, która kombinacja jest dostępna i ile kosztuje.
Dlatego podczas tworzenia sklepów internetowych WooCommerce nie patrzę wyłącznie na wygląd karty produktu. Struktura wariantów musi być również rozsądna technicznie.
Przy starym sklepie warto sprawdzić cały sposób budowy produktów
Jeżeli sklep był rozwijany przez kilka lat, mogę znaleźć jednocześnie rozbudowane warianty, kilka wtyczek swatches, stary motyw i customowy kod, którego nikt już nie używa.
W takim przypadku pojedynczy snippet rzadko będzie najlepszym rozwiązaniem.
Często bardziej opłacalne jest odświeżenie lub przebudowanie istniejącego sklepu i uporządkowanie produktów, template'ów oraz integracji jako jednego procesu.
Wydajność produktu to również część jakości całego sklepu
Na stronynazlecenie.pl zajmuję się tworzeniem i technicznym rozwojem stron oraz sklepów WordPress. Przy wolnym WooCommerce sprawdzam więc nie tylko jeden parametr serwera, ale cały przepływ od bazy danych do tego, co ostatecznie widzi klient w przeglądarce.
Dzięki temu można rozdzielić problem z wariantami od ogólnego problemu wydajności hostingu i poprawić dokładnie to miejsce, które rzeczywiście blokuje sklep.
Moja checklista optymalizacji wariantów WooCommerce
- Sprawdzam liczbę wariantów konkretnego produktu.
- Liczymy faktyczną liczbę kombinacji atrybutów.
- Usuwam kombinacje, których sklep nigdy nie sprzedaje.
- Rozdzielam prawdziwe warianty od prostych dodatków produktowych.
- Nie zwiększam bez potrzeby progu AJAX dla wariantów.
- Sprawdzam ilość danych generowanych w HTML.
- Testuję wpływ Variation Swatches.
- Testuję niestandardowy template i page builder.
- Optymalizuję zdjęcia przypisane do wariantów.
- Sprawdzam duplikaty i reguły „Dowolny…”.
- W panelu kontroluję max_input_vars i limity PHP.
- Sprawdzam zapytania do bazy oraz czas PHP.
- Testuję trwały object cache przy większym sklepie.
- Porównuję wynik przed i po każdej większej zmianie.
- Na końcu sprawdzam produkt na desktopie i telefonie.
Produkt ma setki wariantów i ładuje się kilka sekund?
Mogę sprawdzić strukturę wariantów, próg AJAX, Variation Swatches, template produktu, zapytania do bazy, PHP, cache i serwer. Zamiast dokładać kolejny plugin znajdę element, który rzeczywiście powoduje opóźnienie, i uporządkuję produkt tak, żeby klient szybciej wybrał właściwą wersję i przeszedł do koszyka.
Wolne warianty WooCommerce – najczęstsze pytania
Dlaczego warianty WooCommerce ładują się wolno?
Przyczyną może być bardzo duża liczba kombinacji, ciężkie dane wariantów, dodatkowe zdjęcia, Variation Swatches, niestandardowy template, zapytania do bazy albo ograniczenia serwera. Najpierw porównuję problematyczny produkt z prostszym produktem w tym samym sklepie.
Ile wariantów WooCommerce może mieć jeden produkt?
WooCommerce pozwala tworzyć dużą liczbę wariantów, ale nie oznacza to, że setki lub tysiące kombinacji będą optymalne wydajnościowo. Im więcej wariantów, tym więcej danych sklep może potrzebować do obsługi produktu, panelu oraz integracji.
Co oznacza limit 30 wariantów w WooCommerce?
WooCommerce domyślnie wykorzystuje próg 30 wariantów do zmiany sposobu działania selektorów na stronie produktu. Przy większej liczbie zachowanie jest uproszczone, aby ograniczyć koszt obsługi wielu kombinacji.
Czy warto zwiększyć woocommerce_ajax_variation_threshold?
Nie robię tego automatycznie. Podniesienie progu może poprawić sposób wybierania opcji z punktu widzenia użytkownika, ale przy dużej liczbie wariantów może również pogorszyć wydajność karty produktu. Zmianę poprzedzam pomiarem.
Czy Variation Swatches spowalniają WooCommerce?
Mogą, szczególnie jeśli rozszerzenie przetwarza dodatkowe dane, zdjęcia albo wszystkie warianty podczas generowania strony. Najprościej porównać produkt ze swatchami oraz bez nich na środowisku testowym.
Dlaczego warianty wolno zapisują się w panelu WooCommerce?
Przy dużej liczbie pól sprawdzam PHP max_input_vars, limit pamięci, czas wykonywania, mod_security oraz wydajność serwera. Wolne zapisywanie wariantów w panelu nie musi mieć tej samej przyczyny co wolne wybieranie wariantu przez klienta.
Czy Redis przyspieszy produkty z wieloma wariantami?
Trwały object cache może ograniczyć część powtarzalnych operacji bazodanowych, szczególnie w większym sklepie. Nie zastąpi jednak optymalizacji źle zaprojektowanego produktu z ogromną liczbą zbędnych wariantów.
Czy HPOS przyspiesza warianty produktów WooCommerce?
HPOS optymalizuje przede wszystkim przechowywanie danych zamówień. Nie jest bezpośrednim rozwiązaniem problemów z ładowaniem wariantów na karcie produktu, dlatego te elementy diagnozuję osobno.
Jak zmniejszyć liczbę wariantów bez pogorszenia oferty?
Jako warianty pozostawiam przede wszystkim opcje wymagające własnej ceny, stanu magazynowego, SKU lub innej realnej wersji produktu. Proste dodatki, personalizacje czy usługi można w odpowiednim sklepie obsłużyć innym mechanizmem niż osobny wariant.
Kamil Sudoł – freelancer WordPress & SEO. Od 2015 roku tworzę i rozwijam strony internetowe oraz sklepy WooCommerce, a także zajmuję się SEO i widocznością firm w Google. Na blogu publikuję praktyczne materiały dotyczące WordPressa, SEO, UX i marketingu internetowego.
