Dobrze ustawiona litespeed cache konfiguracja potrafi skrócić czas odpowiedzi serwera bez dokładania kolejnych wtyczek i bez rozbijania układu strony. W praktyce największą różnicę robi nie liczba zaznaczonych opcji, tylko to, które elementy cache zostawisz aktywne, gdzie dodasz wyjątki i jak sprawdzisz, czy sklep, logowanie oraz wersja mobilna nadal działają poprawnie. Poniżej prowadzę przez ustawienia, które naprawdę mają znaczenie, oraz pokazuję, czego nie ruszać na ślepo.
Najpierw cache bazowy, potem wyjątki i dopiero na końcu agresywna optymalizacja
- Na start włączam cache strony i zostawiam większość domyślnych ustawień, bo są sensownie dobrane do typowych witryn.
- Najwięcej uwagi poświęcam wykluczeniom, bo to one decydują, czy koszyk, konto użytkownika i formularze nie zaczną się zachowywać losowo.
- Guest Mode, Guest Optimization, VPI i czułe ustawienia CSS/JS dają zysk, ale mogą też zwiększyć zużycie zasobów lub wprowadzić chwilowe błędy w treści.
- Object Cache ma sens dopiero wtedy, gdy masz Redis, Memcached albo LSMCD i strona nadal mocno obciąża PHP.
- Po zmianach zawsze sprawdzam nagłówki odpowiedzi, a nie tylko wynik w panelu administracyjnym.
Od czego zacząć, żeby konfiguracja miała sens
Ja zaczynam od prostego rozróżnienia: LiteSpeed Cache to jednocześnie page cache i wtyczka optymalizacyjna. Na zwykłym blogu często wystarczy samo włączenie cache strony, a resztę można zostawić na później. Po aktywacji wtyczki wszystko jest wyłączone, więc nie ma sensu od razu klikać każdego przełącznika po kolei.
Ważne jest też środowisko. Pełne buforowanie stron działa wtedy, gdy masz hosting z LiteSpeed albo inny kompatybilny komponent po stronie serwera. Sama wtyczka potrafi jeszcze optymalizować obrazy, CSS i JS, ale bez warstwy serwerowej nie zastąpi pełnego cache. Do tego dochodzą podstawy techniczne: WordPress 5.3+ i PHP 7.2+ to minimum, z którego w 2026 roku i tak nie warto schodzić.
Jeśli chcesz wystartować szybko, użyj presetów zamiast ręcznie grzebać w każdym polu. Preset robi kopię bieżących ustawień, a potem podmienia je na wybraną konfigurację, więc to bezpieczniejszy start niż chaotyczne zaznaczanie wszystkiego naraz. Kiedy baza jest gotowa, przechodzę do ustawień cache, bo tam najszybciej widać realny efekt.
Najpierw ustaw cache bazowy
W podstawowej konfiguracji nie szukam cudów. Chcę, żeby strona zaczęła serwować gotowe odpowiedzi możliwie szybko, a dopiero potem dopasowuję szczegóły do charakteru serwisu. To podejście sprawdza się zarówno na prostym portalu, jak i na większym sklepie czy serwisie usługowym.
| Ustawienie | Co robię na starcie | Dlaczego |
|---|---|---|
Enable Cache |
ON | To faktycznie uruchamia cache strony. Bez tego reszta ustawień nie ma większego znaczenia. |
Cache Logged-in Users |
ON, jeśli masz treści prywatne, konto, panel lub personalizację | Wtyczka zapisuje prywatny cache po IP i sesji. Na zwykłym blogu też zwykle nie szkodzi, ale warto testować w serwisach z dynamicznym panelem użytkownika. |
Cache Commenters |
ON | Przy moderowanych komentarzach użytkownik po wysłaniu wpisu widzi wcześniej zbuforowaną wersję strony. To najczęściej bezpieczne ustawienie. |
Cache REST API |
ON | REST API bywa intensywnie odpytywane przez WordPress i wtyczki. Cache pomaga ograniczyć liczbę wywołań. |
Cache Login Page |
ON | Strona logowania zwykle nie zawiera nic, co trzeba omijać. Wyłączam ją tylko wtedy, gdy faktycznie pokazuje dane zależne od użytkownika. |
Cache Mobile |
OFF, chyba że masz osobną wersję mobilną | Ten tryb jest potrzebny głównie przy niereatywnych motywach, AMP, osobnych widgetach mobilnych albo przy agresywnej optymalizacji z Guest Mode. |
Browser Cache |
ON | Statyczne pliki lądują lokalnie w przeglądarce użytkownika. Dla obrazów, CSS i JS to bardzo tani zysk. |
Purge All on Upgrade |
ON | Po aktualizacji wtyczek, motywu lub rdzenia WordPressa zmienia się też zachowanie frontu. Ja wolę mieć pewność, że stary cache nie zostanie po zmianach. |
Przy browser cache trzymam się jeszcze jednej zasady: jeśli masz dostęp do panelu serwera, możesz ustawić nagłówki po stronie LiteSpeed Web Server, ale nie ustawiaj Expires Default dla całego HTML, bo to potrafi wejść w konflikt z LSCache i serwować nieświeże strony. Dla statycznych plików warto myśleć o roku, czyli 31557600 sekund, a dla typowych zasobów cache strony domyślnie siedzi w okolicach 604800 sekund, czyli 7 dni. Kiedy bazowy cache już działa, przechodzę do wyjątków, bo to one najczęściej psują koszyk, logowanie i personalizację.
Wykluczenia i odświeżanie cache tam najczęściej pojawiają się błędy
Na tej sekcji najłatwiej zrobić sobie problem, jeśli potraktuje się ją zbyt lekko. Wystarczy jeden zbyt szeroki cookie albo nieostry wzorzec URI i nagle cache przestaje działać na pół witryny. Dlatego wykluczenia ustawiam ostrożnie, najlepiej po jednej zmianie i z testem w przeglądarce prywatnej.
| Reguła | Kiedy jej używam | Na co uważam |
|---|---|---|
Do Not Cache URIs |
Gdy mam strony dynamiczne, np. koszyk, checkout, konto użytkownika, panel lub formularze z sesją | W WooCommerce wiele stron wyklucza się automatycznie, ale warto to sprawdzić po instalacji i po większych zmianach. |
Do Not Cache Cookies |
Gdy jakaś wtyczka ustawia cookie zależne od treści lub stanu użytkownika | Każdy cookie wpisuję osobno. Jeśli cookie występuje na każdej podstronie, mogę przez przypadek wyłączyć cache praktycznie całej witryny. |
Do Not Cache Roles i Do Not Cache User Agents
|
Gdy chcę odseparować administratorów, testerów lub określone boty | Przydaje się w stagingu i podczas wdrożeń, ale na produkcji nie ma sensu wykluczać więcej niż trzeba. |
Force Cache URIs / Force Public Cache URIs
|
Gdy jakaś ważna strona zbyt agresywnie wypada z cache i powinna być buforowana mimo innych reguł | To narzędzie do naprawiania konkretnego problemu, nie do maskowania złej struktury serwisu. |
Drop Query String |
Gdy parametry typu utm_, kampanie lub analityka nie zmieniają treści strony |
Nie używam tego dla filtrów, sortowania, wariantów produktu czy kolorystyki, jeśli parametr realnie zmienia widok. |
Scheduled Purge URLs |
Gdy treść jest zależna od zewnętrznego źródła i trzeba ją odświeżać o konkretnej porze | To ma sens przy importach, zewnętrznych feedach i automatycznych aktualizacjach danych. |
Serve Stale |
Gdy witryna ma duży ruch i nie chcę, by pierwszy request po purge'u wywołał lawinę zapytań do PHP | Dobre na ruchliwe serwisy, mniej potrzebne na małych stronach. Akceptuję tu kompromis: chwilowo stara kopia zamiast większego obciążenia serwera. |
Przy URIs i harmonogramach purge pamiętam o składni: można używać znaczników początku i końca ścieżki, na przykład ^ i $, żeby doprecyzować dopasowanie. Z kolei przy treściach z komentarzami albo odświeżanych zewnętrznie czasem ustawiam purge według harmonogramu, zamiast liczyć wyłącznie na automatyczne reguły. Gdy wyjątki są pod kontrolą, można zająć się frontem, czyli CSS, JS i obrazami.
Optymalizacja CSS, JS i obrazów bez psucia UX
To jest obszar, w którym najłatwiej uzyskać lepsze wyniki testów, ale też najłatwiej wprowadzić regresję. Ja traktuję optymalizację frontu jako osobny etap, nie jako domyślny stan „włącz wszystko”. Najpierw sprawdzam, czy strona nie łamie układu, a dopiero potem dociskam parametry.
Lazy load i obrazy
Lazy Load Images zostawiam włączone, ale wykluczam elementy widoczne od razu po wejściu na stronę: logo, pierwszy baner, główną grafikę nad zagięciem i czasem iframe z osadzonym materiałem. Dzięki temu nie przesuwam układu i nie generuję irytujących skoków treści. Jeśli widzę, że konkretna sekcja ładuje się za późno, dopisuję ją do Lazy Load Image Excludes albo całe URI do Lazy Load URI Excludes.
W bardziej złożonych wdrożeniach przydaje się VPI, czyli Viewport Images. Ta funkcja rozpoznaje obrazy widoczne w pierwszym ekranie i wyłącza je z lazy load, ale działa tylko wtedy, gdy Lazy Load Images jest włączone i korzystasz z QUIC.cloud. To nie jest darmowy „bonus za kliknięcie”, tylko usługa, która może zużywać limit i wywoływać dodatkowe procesy po stronie chmury. W praktyce sięgam po nią, gdy zależy mi na dobrym LCP i stabilnym pierwszym widoku na dużym serwisie.
JS i CSS
Przy JavaScript najczęściej używam JS Delayed Includes tylko dla konkretnych plików lub fragmentów kodu, które naprawdę można opóźnić. To ważne, bo jeśli ustawisz Load JS Deferred na tryb Deferred, to opóźnianie inline JS przestaje działać w ten sam sposób. W praktyce najpierw szukam skryptów, które nie są krytyczne dla pierwszego renderu, a dopiero później ruszam resztę.
Podobnie z CSS: nie włączam masowo wszystkich przełączników tylko po to, by zobaczyć lepszy wynik w testach. Jeśli strona po optymalizacji zaczyna tracić style na mobile albo renderuje się z opóźnieniem, cofnięcie jednej zmiany zwykle daje więcej niż dokładanie kolejnych obejść. Dla mnie lepszy jest jeden dobrze dopasowany wyjątek niż pięć losowych ustawień, które tylko zwiększają chaos.
Przeczytaj również: Jak wyczyścić pamięć podręczną? Poradnik krok po kroku
Guest Mode i Guest Optimization
Guest Mode i Guest Optimization to ustawienia, które poprawiają wynik pierwszego wejścia, ale mają realne koszty. Przy Guest Mode pierwszy gość dostaje domyślną wersję strony z cache, a dopiero potem przez Ajax dociągana jest właściwa wersja. To potrafi przyspieszyć odpowiedź serwera, ale na bardziej złożonych stronach może przez moment pokazać złą walutę, zły język albo nieidealne ceny.
Guest Optimization idzie krok dalej i dla kwalifikujących się żądań uruchamia maksymalny poziom optymalizacji, nawet jeśli normalnie są one wyłączone. To świetnie wygląda w PageSpeed, ale oznacza też dodatkowe zużycie QUIC.cloud, większe obciążenie przez CCSS, UCSS i VPI, a czasem także większą liczbę crawlerów. Ja włączam to dopiero wtedy, gdy mam prosty, dobrze przetestowany serwis albo gdy naprawdę potrzebuję agresywnego wyniku testów i wiem, że serwer to udźwignie. Kiedy front jest już poukładany, zostaje serwer i usługi pomocnicze, które decydują o stabilności przy większym ruchu.
Object cache, crawler i QUIC.cloud kiedy naprawdę mają sens
W tej części najczęściej widać różnicę między „wtyczka jest zainstalowana” a „serwis jest sensownie skonfigurowany”. Nie każda strona potrzebuje wszystkiego naraz. Ja dobieram te funkcje tylko wtedy, gdy wiem, jaki problem mają rozwiązać.
| Element | Kiedy go używam | Na co patrzę |
|---|---|---|
| Object Cache | Gdy strona nadal mocno obciąża PHP i mam działający Redis, Memcached albo LSMCD | LSCache nie daje object cache sam z siebie. Potrzebujesz zewnętrznego silnika i odpowiedniego rozszerzenia PHP, np. php-redis lub php-memcached. |
| Crawler | Na dużych portalach i sklepach, gdzie ważne jest „podgrzewanie” cache przed ruchem użytkowników | Crawler musi być włączony na poziomie serwera albo virtual hosta przez administratora. Bez tego wtyczka nie zrobi wszystkiego sama. |
| QUIC.cloud | Gdy chcę korzystać z CCSS, UCSS, VPI lub innych usług optymalizacyjnych | Od wersji 7 nie opieram już konfiguracji na Domain Key. Łączę usługę przez General > Online Services. |
| Server IP | Gdy chcę ograniczyć zbędne lookupy DNS/CDN przy crawlerze i usługach zewnętrznych | To mały detal, ale na dużej liczbie adresów potrafi uprościć całą ścieżkę i zmniejszyć narzut. |
Object cache ma największy sens wtedy, gdy WordPress faktycznie buduje strony przez PHP. Jeśli większość ruchu obsługuje page cache, zewnętrzny cache obiektów staje się dodatkiem, a nie fundamentem. Crawler z kolei świetnie pasuje do serwisów o dużym ruchu, ale na małych stronach bywa po prostu niepotrzebnym obciążeniem. Jeżeli masz też Cloudflare, pamiętaj o jednej rzeczy: nie dubluję page cache po obu stronach, bo wtedy zamiast przyspieszenia zwykle pojawia się konflikt warstw. Na końcu sprawdzam wszystko w przeglądarce i dopiero wtedy uznaję konfigurację za gotową.
Jak sprawdzam, czy wszystko działa i co zostawiam na końcu
Po każdej większej zmianie testuję stronę tak, jak zobaczy ją zwykły użytkownik. Otwieram ją w trybie prywatnym, odpalam narzędzia deweloperskie i patrzę nie tylko na wygląd, ale też na odpowiedź serwera. Jeśli jakaś strona ma być wykluczona z cache, w nagłówkach powinien pojawić się X-LiteSpeed-Cache-Control: no-cache. Jeśli cache ma działać, nie chcę widzieć sygnałów, że coś przypadkiem omija warstwę buforowania.
- Sprawdzam osobno stronę główną, wpis, stronę logowania, koszyk, checkout i konto użytkownika.
- Porównuję pierwszy i drugi request w trybie prywatnym, bo dopiero drugi pokazuje realny efekt cache.
- Po zmianach w CSS/JS czyścię nie tylko zwykły cache, ale też
Purge All - CSS/JS, jeśli dotykałem optymalizacji frontu. - Jeśli testuję rolę administratora albo stronę z personalizacją, upewniam się, że nie zostałem przypadkiem na cache prywatnym.
- Na stronie z dynamicznymi treściami zewnętrznymi pilnuję harmonogramu purge zamiast liczyć, że wszystko odświeży się samo.
Moja bezpieczna konfiguracja startowa wygląda zwykle tak: Enable Cache włączone, Browser Cache włączone, Purge All on Upgrade aktywne, Cache Mobile wyłączone na responsywnym motywie, Guest Mode wyłączony dopóki nie ma uzasadnienia biznesowego i Guest Optimization tylko po testach wydajnościowych. Jeśli serwis jest WooCommerce, najpierw dopieszczam koszyk, checkout i konto, a dopiero potem bawię się w mocniejsze skracanie JS i obrazów. W praktyce najwięcej daje prosty układ: cache bazowy, sensowne wykluczenia, ostrożna optymalizacja frontu i żadnych dublujących się warstw po stronie hostingu lub Cloudflare.
