Sklep WooCommerce najczęściej zwalnia przez brak cache stron, zbyt mało PHP workers w szczycie, duże opcje autoload w bazie, zalegające zadania w tle i wtyczki odpytujące zewnętrzne serwisy. Zacznij od pomiaru czasu do pierwszego bajtu (TTFB): dobrze to do 0,8 s; na sklepie z działającym cache potrafi spaść z 0,78 s do 0,11 s.
Najpierw zmierz, potem naprawiaj
TTFB strony produktu i koszyka
W narzędziach deweloperskich przeglądarki (zakładka Sieć) albo w PageSpeed Insights. Produkt z cache powinien odpowiadać w ułamku sekundy; koszyk zawsze liczy się od nowa.
Nagłówek cache
Na LiteSpeed sprawdź nagłówek
X-LiteSpeed-Cache.hitoznacza stronę z cache,missalbo brak nagłówka — liczoną od zera.Query Monitor
Wtyczka Query Monitor pokaże najwolniejsze zapytania do bazy, zapytania HTTP do innych serwisów i wtyczkę, która je wywołuje.
Zużycie zasobów w panelu
Jeśli w szczycie pojawiają się błędy 508 albo 503, problemem są limity procesów, nie kod.
10 przyczyn, od najczęstszej
| Przyczyna | Jak rozpoznać | Co zrobić |
|---|---|---|
| 1. Brak cache stron | Brak X-LiteSpeed-Cache: hit na produktach | Włączyć LSCache albo inny cache stron |
| 2. Brak object cache | Koszyk i kokpit wolne mimo cache stron | Redis jako object cache — jak sprawdzić |
| 3. Za mało PHP workers | Błędy 508/503 albo kolejka w szczycie | Policz potrzebną liczbę |
4. Duże autoload w wp_options | Suma opcji ładowanych automatycznie powyżej ok. 800 KB (próg ostrzeżenia w Kondycji witryny) | Wyłączyć autoload dla dużych opcji porzuconych wtyczek |
| 5. Zalegające zadania w tle | Tysiące zadań w WooCommerce → Status → Zaplanowane działania | Usunąć zakończone, naprawić te, które się powtarzają |
| 6. WP-Cron uruchamiany przez odwiedzających | Skoki czasu odpowiedzi co kilka minut | Przenieść do systemowego crona |
| 7. Wtyczka odpytuje zewnętrzny serwis | Query Monitor: wolne zapytania HTTP | Cache wyników albo inna wtyczka |
| 8. Cart fragments na każdej stronie | wc-ajax=get_refreshed_fragments przy każdej odsłonie | Ograniczyć do stron, które pokazują mini-koszyk |
| 9. Stara wersja PHP | PHP 7.x w panelu | Przejść na PHP 8.x po sprawdzeniu zgodności wtyczek |
| 10. Ciężkie zdjęcia i skrypty | Słabe LCP przy szybkim TTFB | WebP/AVIF, leniwe ładowanie, mniej skryptów zewnętrznych |
Rozmiar autoload sprawdzisz w bazie zapytaniem (od WordPressa 6.6 opcje ładowane automatycznie mają wartości yes, on, auto-on lub auto):
SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Kiedy winny jest hosting
Jeśli strona z cache odpowiada szybko, a koszyk i kokpit są wolne mimo object cache i czystej bazy, ograniczeniem jest zwykle moc planu: liczba PHP workers, procesor albo dysk. Na hostingu Aderlo Cloud LiteSpeed Enterprise, LSCache i osobna instancja Redis dla każdego konta są skonfigurowane od pierwszego dnia; na jednym z naszych sklepów to 0,78 s do pierwszego bajtu bez cache i 0,11 s z cache.
Porównaj plany Aderlo Cloud →Najczęstsze pytania
- Jaki TTFB jest dobry dla sklepu WooCommerce?
- Google uznaje za dobry wynik do 0,8 s. Strony produktów podawane z cache powinny być wyraźnie poniżej; koszyk i zamówienie zawsze są liczone od nowa, więc tam liczy się moc serwera i object cache.
- Czy więcej RAM przyspieszy sklep?
- Tylko jeśli sklepowi brakuje pamięci. Częściej ograniczeniem są PHP workers, wolne zapytania do bazy albo brak cache — warto to zmierzyć przed zmianą planu.