- LiteSpeed Cache robi cache całych stron tylko na serwerze LiteSpeed (albo przez QUIC.cloud). Na Apache i nginx działają jedynie dodatki, takie jak minifikacja czy object cache.
- Mój pomiar z 03.11.2026: ten sam artykuł z cache odpowiadał w 117 i 122 ms (mediana dwóch serii po 10 prób), bez cache w 318 i 719 ms. Strona główna sklepu: 112 ms z cache, 891 ms bez.
- Koszyka, kasy i konta klienta nie wpisujemy ręcznie do wykluczeń. Wtyczka wyłącza je sama, a Ty sprawdzasz to nagłówkiem. Koszyk zawsze buduje PHP: w sklepie z branży 18+ mediana to 962 ms.
- Nie klikamy „Purge All”. W wersji 7.9.2 czyści on całą bazę Redisa na koncie. U nas Redis dostał 84 467 takich poleceń w 66 dni.
- Markdown dla agentów AI podajemy pod tym samym adresem, ale jedna reguła w .htaccess trzyma go poza cache. Przeglądarka dalej dostaje HTML z cache.
Spis treści · 9 części
- 01LiteSpeed Cache w WordPressie: ile naprawdę przyspiesza stronę?
- 02Jakie ustawienia LiteSpeed Cache stosujemy na naszym serwerze?
- 03Jak ustawić LiteSpeed Cache w WooCommerce, żeby nie zepsuć koszyka?
- 04Purge All w LiteSpeed Cache: dlaczego go nie klikamy?
- 05Markdown dla agentów AI a LiteSpeed Cache: jak nie zatruć cache?
- 06Których opcji LiteSpeed Cache nie włączamy i dlaczego?
- 07Jak sprawdzić, czy LiteSpeed Cache działa na Twojej stronie?
- 08Najczęstsze pytania
- 09Źródła
Ten tekst jest dla Ciebie, jeśli masz WordPressa albo sklep WooCommerce na hostingu z LiteSpeed i nie wiesz, które z setek przełączników wtyczki LiteSpeed Cache ruszyć, żeby nie zepsuć koszyka ani wyglądu strony.
Nie przepisuję dokumentacji. Pokazuję ustawienia, które 03.11.2026 odczytałem z naszego serwera web01 w Aderlo Cloud. Na moim koncie jest 28 instalacji WordPressa, z czego 24 ma aktywną wtyczkę LiteSpeed Cache 7.9.2. Do tego pomiar przed i po na tych samych adresach oraz cztery wpadki, które kosztowały nas najwięcej czasu.
LiteSpeed Cache w WordPressie: ile naprawdę przyspiesza stronę?
LiteSpeed Cache w WordPressie skraca czas odpowiedzi serwera kilkukrotnie, bo gotową stronę oddaje serwer WWW bez uruchamiania PHP. 03.11.2026 ten sam artykuł odpowiadał z cache w 117 ms, a bez cache w 318 ms. W drugiej serii, przy większym ruchu na serwerze, było to 122 ms wobec 719 ms.
Mierzyłem TTFB, czyli czas do pierwszego bajtu odpowiedzi, narzędziem curl z mojego komputera w Polsce. Na każdy adres wysłałem 2 żądania rozgrzewające i 10 zwykłych. Potem 10 żądań z losowym dopiskiem w adresie (?ii_pomiar=…), którego cache nie zna, więc WordPress musi zbudować stronę od nowa. Nagłówek x-litespeed-cache potwierdzał hit przy zwykłym adresie i miss przy dopisku w 100% prób.
| Adres | Godzina | Z cache | Bez cache |
|---|---|---|---|
| artykuł „Jaki hosting wybrać”, seria 1 | 16:01 | 117 ms (110–139) | 318 ms (311–818) |
| ten sam artykuł, seria 2 | 16:03 | 122 ms (115–171) | 719 ms (460–1716) |
| strona główna sklepu rozkoszownia.pl (WooCommerce) | 16:01 | 112 ms (111–164) | 891 ms (855–2317) |
| strona główna sklepu z branży 18+ | 16:03 | 115 ms (112–128) | nie mierzyłem |
Wynik zgadza się z pomiarem z 27.10.2026, który opisałem w tekście o tym, jaki hosting wybrać: strony floty z cache odpowiadały wtedy w 97–131 ms, bez cache w 249–887 ms. Z cache wszystko mieści się daleko pod progiem 0,8 s, który Google uznaje za dobry TTFB. Bez cache czas zależy od pracy PHP i obciążenia serwera, dlatego druga seria wyszła ponad dwa razy wolniej.
Jakie ustawienia LiteSpeed Cache stosujemy na naszym serwerze?
Na naszym serwerze LiteSpeed Cache ma włączony cache stron, cache prywatny dla zalogowanych, object cache na Redisie oraz minifikację CSS i HTML. Minifikacja i łączenie JavaScriptu, lazy load, crawler na blogach i tryb gościa są wyłączone. Na blogu i w obu sklepach, które sprawdziłem 03.11.2026, ustawienia są takie same, z wyjątkiem crawlera.
| Ustawienie | Wartość u nas | Dlaczego |
|---|---|---|
| Cache stron (Enable Cache) | włączony | to jest cała przewaga z tabeli wyżej |
| Cache zalogowanych (Cache Logged-in Users) | włączony, prywatny | każdy zalogowany ma własną kopię, nikt nie zobaczy cudzej |
| Czas życia stron publicznych | 604 800 s (7 dni) | wtyczka sama czyści stronę po edycji, więc długi czas jest bezpieczny |
| Czas życia cache prywatnego | 1 800 s (30 min) | wartość domyślna, wystarcza |
| Strony błędów | 404: 3 600 s, 500: 600 s | uwaga: zapamiętane 404 potrafią przeżyć poprawkę |
| Pomijane parametry adresu | fbclid, gclid, utm*, _ga | wejście z reklamy trafia w tę samą kopię strony |
| Object cache | Redis, osobny na konto, 360 s | przyspiesza strony, których cache stron nie obsłuży |
| Sesje koszyka w Redisie | nie (grupa wc_session_id nietrwała) | sesja klienta zostaje w bazie WooCommerce |
| Minifikacja CSS / HTML | włączona / włączona | bezpieczne przy naszych motywach |
| Minifikacja i łączenie JS | wyłączone | to najczęstsza przyczyna zepsutych koszyków |
| Cache wersji mobilnej, ESI, tryb gościa | wyłączone | motywy są responsywne, a ESI nie było potrzebne |
| Crawler | blogi: wyłączony; sklep 18+: włączony, próg obciążenia 6 | rozgrzewa cache, ale zjada procesor konta |
Lazy load i UCSS mamy wyłączone, a ich wpływu jeszcze nie mierzyłem, więc ich nie oceniam. Optymalizacja frontu (waga obrazków i skryptów) to u nas najmniej dopracowana część.
Jak ustawić LiteSpeed Cache w WooCommerce, żeby nie zepsuć koszyka?
LiteSpeed Cache w WooCommerce nie psuje koszyka, jeśli zostawisz stronom koszyka, kasy i konta wykluczenia, które wtyczka nadaje im sama, i wyłączysz z cache API sklepu. 03.11.2026 koszyk, kasa i konto w obu naszych sklepach odpowiadały nagłówkiem x-litespeed-cache-control: no-cache bez żadnego wpisu w ustawieniach.
Wtyczka rozpoznaje te strony po identyfikatorach z ustawień WooCommerce, a nie po adresie. Gdy klient ma coś w koszyku, dodaje do klucza cache osobny wariant, więc nie dostanie kopii strony zrobionej dla kogoś innego. Szkody robią zwykle „poprawki” dopisane na wszelki wypadek.
- Sprawdź, czy serwer to LiteSpeed. W odpowiedzi strony szukaj nagłówka
x-litespeed-cache. Jeśli go nie ma, wtyczka nie zrobi cache stron, a koszyk jest bezpieczny z innego powodu. - Odczytaj prawdziwy adres koszyka. W jednym sklepie to
/cart/, w drugim/koszyk/. Strzał w zły adres daje 404, które cache zapamiętuje na godzinę, i wygląda to jak „koszyk w cache”. - Sprawdź nagłówek koszyka, kasy i konta. Każda z tych stron ma zwracać
x-litespeed-cache-control: no-cache. Jeśli tak jest, nie dopisuj ich do „Do Not Cache URIs”. - Wyłącz z cache API sklepu. Bloki koszyka korzystają z adresów
/wp-json/wc/store/. Wersja 7.9.2 wyłącza je z cache sama. Na naszym serwerze od 21.08.2026 cały/wp-json/i zapytania OPTIONS omijają cache regułą serwera, bo wcześniej część sklepów pokazywała gościom wspólny koszyk. - Nie łącz i nie minifikuj JavaScriptu w sklepie. Testy tylko na kopii sklepu.
- Zrób zamówienie testowe po każdej zmianie. W oknie prywatnym, na telefonie i komputerze; poprawkę sprawdzaj czystym adresem, bo adres z dopiskiem omija cache.
W sklepie z branży 18+ na platformie GAPLI strona główna wychodzi z cache w 115 ms, a koszyk, którego cache nie obsługuje, potrzebował 03.11.2026 od 0,74 do 1,83 s (mediana 962 ms z 10 prób). Ten sklep ma kilkanaście osób dziennie, konwersję 1,76% po naprawie płatności i gardło na przejściu z koszyka do zamówienia: 14% (stan na 24.10.2026). Cache tego gardła nie usunie, bo koszyk zawsze liczy PHP. Tam pomagają lżejsze wtyczki, object cache i prostszy koszyk, nie przełączniki w LiteSpeed.
Purge All w LiteSpeed Cache: dlaczego go nie klikamy?
Purge All w LiteSpeed Cache 7.9.2 czyści nie tylko cache stron, ale też cały object cache, wywołując w Redisie polecenie FLUSHDB. Jeśli kilka WordPressów dzieli jeden Redis, czyszczenie jednej strony kasuje pamięć podręczną wszystkich. Na moim koncie Redis dostał 84 467 takich poleceń w 66 dni pracy, średnio około 1 280 na dobę.
Sprawdziłem to w kodzie wtyczki: funkcja flush() w pliku object cache woła flushDb(), a nie kasowanie kluczy jednej strony. Skutek widziałem na żywo. 03.11.2026 o 16:03 baza Redisa mojego konta miała 749 219 kluczy, a o 16:06, po dwóch FLUSHDB, 6 991. Wszystkie strony na koncie musiały budować tę pamięć od nowa. Nie ustalałem, która wtyczka wysłała akurat te dwa polecenia.
Purge All ma jeszcze jeden skutek: kasuje liczniki i blokady trzymane w transientach. U nas przestał przez to działać limit komentarzy na jednym z blogów, bo licznik znikał kilka razy w ciągu 10 minut. Limity, które muszą przetrwać, przenieśliśmy do zwykłej tabeli w MySQL.
Zamiast Purge All nasze skrypty publikacji i wdrożeń czyszczą sam cache stron poleceniem, które nie dotyka Redisa:
wp eval "do_action('litespeed_purge', '*');"
W panelu odpowiednikiem jest czyszczenie pojedynczych stron albo całego cache stron, bez opcji „wszystko”. Część wtyczek sklepowych, także wtyczki synchronizacji GAPLI, czyści object cache sama przy aktualizacji stanów magazynowych. To jest na naszej liście do poprawienia po stronie platformy.
Markdown dla agentów AI a LiteSpeed Cache: jak nie zatruć cache?
Markdown dla agentów AI pod tym samym adresem co HTML jest bezpieczny tylko wtedy, gdy żądanie z nagłówkiem Accept: text/markdown w ogóle nie czyta i nie zapisuje cache stron. LiteSpeed nie rozróżnia wariantów po nagłówku Accept, więc bez reguły agent dostałby HTML, a przy pechu przeglądarka dostałaby Markdown.
Agentom podajemy lekką wersję tekstu, bo łatwiej ją przeczytać i zacytować. Szerzej piszę o tym w tekście o pozycjonowaniu w AI. Sam nagłówek Vary: Accept nie wystarcza. W pliku .htaccess, przed blokiem wtyczki, mamy:
RewriteCond %{HTTP_ACCEPT} text/(x-)?markdown [NC]
RewriteRule .* - [E=Cache-Control:no-cache]
Sprawdzenie 03.11.2026 na tym serwisie: dwa żądania z Accept: text/markdown dostały content-type: text/markdown i no-cache, w 293 i 329 ms. Następne żądanie przeglądarki pod ten sam adres dostało HTML z cache (hit) w 115 ms. Tę samą regułę mają oba sklepy.
Których opcji LiteSpeed Cache nie włączamy i dlaczego?
Nie włączamy łączenia i minifikacji JavaScriptu w sklepach, trybu gościa, cache wersji mobilnej i crawlera z wysokim progiem. U nas psuły koszyk lub wygląd strony albo zabierały procesor klientom.
- Crawler z wysokim progiem. Crawler odwiedza strony, żeby cache był gotowy przed klientem. Próg obciążenia dotyczy całego serwera, nie Twojego konta. Ustawiony za wysoko jedzie non stop i zjada limit procesora sklepu. W sklepie 18+ mamy próg 6, domyślne 1 sprawia, że na zajętym serwerze crawler prawie nigdy nie rusza.
- Minifikacja CSS po zmianie motywu. Na jednej ze stron na naszym serwerze po wgraniu nowego motywu wtyczka podmieniła odnośniki do stylów na pliki, których nie wygenerowała, i serwis wyświetlił się jako goły tekst. Wyczyszczenie cache we wtyczce nie pomogło, trzeba było wyczyścić katalog cache na serwerze.
- Ręczne wyłączenie cache w .htaccess. Na jednej z naszych stron „tymczasowa” reguła wyłączająca cache strony głównej została po pracach, dla których powstała, i wyszła dopiero w pomiarze czasu odpowiedzi. Objaw: wtyczka wysyła
public, a serwer odpowiada miss przy każdym wejściu.
Jak sprawdzić, czy LiteSpeed Cache działa na Twojej stronie?
Czy LiteSpeed Cache działa, sprawdzisz w minutę nagłówkiem x-litespeed-cache: przy drugim wejściu na ten sam adres powinien pokazać hit, a strona odpowiedzieć szybciej niż przy pierwszym. Na naszych stronach 03.11.2026 hit oznaczał 110–171 ms, a miss od 311 ms do ponad 2 s.
- Odczytaj nagłówki. W Terminalu:
curl -sI https://twojadomena.pl/ | grep -i litespeed. Powtórz dwa razy. Za drugim razem ma być hit. - Zmierz czas z cache.
curl -s -o /dev/null -w "%{time_starttransfer}\n" https://twojadomena.pl/, 10 razy, weź środkowy wynik. - Zmierz czas bez cache. To samo z dopiskiem ?test=1, ?test=2 i tak dalej. Różnica pokazuje, ile daje cache i jak szybki jest sam serwer.
- Sprawdź koszyk. Koszyk, kasa i konto muszą zwracać no-cache. Jeśli koszyk pokazuje hit, natychmiast wyłącz cache i szukaj przyczyny.
Jeśli nagłówka nie ma wcale, Twój hosting najpewniej nie działa na LiteSpeed i cache stron z tej wtyczki nie ruszy. Wtedy wybierasz inną wtyczkę cache albo inny hosting. Koszty tej decyzji rozpisałem w tekście o tym, ile kosztuje hosting i domena. Aderlo, czyli moja firma, ma LiteSpeed i Redisa w każdym planie, ale jeśli prowadzisz wizytówkę z kilkoma wejściami dziennie, tańszy hosting z LiteSpeed wystarczy. Kolejne teksty cyklu „Hosting od środka” znajdziesz w dziale Strona i ruch.
Najczęstsze pytania
Czy LiteSpeed Cache działa na każdym hostingu?
Nie w pełni. Cache całych stron, cache prywatny i crawler wymagają serwera LiteSpeed, OpenLiteSpeed albo CDN QUIC.cloud. Na Apache i nginx działa tylko część funkcji, na przykład minifikacja i object cache. Sprawdzisz to nagłówkiem x-litespeed-cache.
Czy LiteSpeed Cache psuje koszyk WooCommerce?
Przy domyślnych ustawieniach nie. Wtyczka sama wyłącza z cache koszyk, kasę i konto, a od wersji 7.9.2 także API koszyka. Koszyki psują zwykle łączenie i minifikacja JavaScriptu oraz ręczne reguły dopisane w .htaccess.
Czym różni się Purge All od czyszczenia cache stron?
Purge All w wersji 7.9.2 czyści cache stron i cały Redis, czyli object cache wszystkich stron korzystających z tej samej bazy Redisa. Czyszczenie cache stron, w WP-CLI przez litespeed_purge z gwiazdką, zostawia Redisa w spokoju.
Czy włączać crawler LiteSpeed Cache?
Na blogu zwykle nie trzeba, bo strony trafiają do cache przy pierwszej wizycie. W sklepie z tysiącami produktów pomaga, ale ustaw niski próg obciążenia i po włączeniu zmierz czas odpowiedzi strony bez cache.
Źródła
- WordPress.org, LiteSpeed Cache: strona wtyczki, wersja 7.9.2 z 20.10.2026, wymagania funkcji „LiteSpeed Exclusive”, ponad 7 mln aktywnych instalacji (sprawdzone 03.11.2026): wordpress.org
- LiteSpeed Technologies, LSCache for WordPress, dokumentacja ustawień Cache (sprawdzone 03.11.2026): docs.litespeedtech.com
- Google, web.dev: Time to First Byte (TTFB), dobry wynik do 0,8 s (sprawdzone 03.11.2026): web.dev
- Pomiar własny: curl 8.7.1, 03.11.2026 16:01–16:06, po 10 prób TTFB z cache i bez cache na adres, nagłówki koszyka, kasy, konta i API koszyka w dwóch sklepach, żądania z Accept: text/markdown; odczyt ustawień LiteSpeed Cache (WP-CLI), reguł .htaccess i statystyk Redisa na serwerze web01 tego samego dnia.
Stan na 03.11.2026. Tego dnia między 16:00 a 16:07 odczytałem z serwera web01 ustawienia LiteSpeed Cache 7.9.2 (blog i dwa sklepy), reguły .htaccess, kod wtyczki i licznik FLUSHDB w Redisie, a z mojego komputera zmierzyłem TTFB z cache i bez oraz nagłówki koszyka i odpowiedzi Markdown.
