Problemy z cache WordPress – LiteSpeed, WP Rocket, Redis 2026

Klasyczna sytuacja: zmieniasz cenę produktu w panelu, klikasz Zaktualizuj, otwierasz stronę – a tam ciągle stara kwota. Nim oskarżysz WordPressa o awarię, zrozum, że Twoja strona przechodzi przez minimum cztery warstwy buforowania, zanim trafi do oczu klienta.

Poziom 1 – cache przeglądarki. Twój Chrome lub Firefox trzyma kopie obrazków, CSS i czasem całych stron HTML. Hard refresh (Ctrl+Shift+R na Windows, Cmd+Shift+R na Macu) wymusza pobranie świeżej wersji. To zawsze pierwszy strzał, zanim zaczniesz grzebać głębiej.

Poziom 2 – plugin cache. LiteSpeed Cache, WP Rocket, W3 Total Cache czy WP Super Cache zapisują wygenerowane strony jako statyczne pliki HTML w katalogu `wp-content/cache/`. Zamiast generować stronę za każdym razem (PHP plus zapytania do bazy), serwer wysyła gotowy plik. Szybko, ale po edycji wpisu plugin musi tę kopię unieważnić.

Poziom 3 – cache serwera. OPcache trzyma skompilowany kod PHP w pamięci, Varnish lub FastCGI cache na poziomie Nginx serwują pełne odpowiedzi HTTP. Te warstwy działają niezależnie od WordPressa i często wtyczka cache nie ma do nich dostępu.

Poziom 4 – CDN. Cloudflare, BunnyCDN czy KeyCDN buforują zawartość na setkach serwerów na świecie. Edge cache trzyma stronę, dopóki nie wygaśnie TTL albo ręcznie nie zrobisz purge.

Przy diagnostyce zacznij od najbliższego użytkownikowi (przeglądarka) i schodź w głąb. Jeśli masz wrażenie, że strona ogólnie wolno odpowiada, sprawdź też nasz przewodnik WordPress wolno się ładuje – jak naprawić – cache to jedna noga problemu, a hosting i baza druga.

Najprostsza diagnostyka to otwarcie DevTools w przeglądarce (F12), zakładka Network, odświeżenie strony i kliknięcie pierwszego dokumentu HTML. W panelu Headers zobaczysz odpowiedź serwera. Tam żyje prawda.

Kluczowe nagłówki, których szukasz:

• `X-LiteSpeed-Cache: hit` – LiteSpeed Cache obsłużył odpowiedź ze swojego cache
• `X-Cache: HIT` lub `MISS` – Varnish lub generyczny cache reverse proxy
• `CF-Cache-Status: HIT/MISS/DYNAMIC/BYPASS` – Cloudflare
• `Age: 3600` – jak długo (sekundy) odpowiedź siedzi w cache
• `Cache-Control: max-age=86400` – instrukcja dla przeglądarki/CDN, jak długo trzymać
• `X-WP-Rocket: cached` – WP Rocket

Oto tabela mapująca nagłówek na warstwę cache:

Jeśli widzisz `X-LiteSpeed-Cache: hit` i `Age: 7200`, to LiteSpeed serwuje 2-godzinną kopię. Plugin flush rozwiąże sprawę. Jeśli widzisz `CF-Cache-Status: HIT`, sam flush w WP nic nie da – musisz wyczyścić Cloudflare. Pokażę to w sekcji 5.

Alternatywnie użyj curl z linii komend: `curl -I https://twojadomena.pl/` – wypluje wszystkie nagłówki bez konieczności klikania w przeglądarce.

Każdy plugin cache ma własne menu i logikę. Oto procedury, które działają w 95% przypadków.

LiteSpeed Cache (najlepszy darmowy plugin, działa tylko na hostingu z LiteSpeed lub OpenLiteSpeed):

1. WordPress Admin > LiteSpeed Cache > Toolbox
2. Kliknij Purge All – LSCache lub Empty Entire Cache
3. Jeśli masz Critical CSS lub Image Optimization, dorzuć Purge All – CSS/JS Cache
4. Z linii komend: `wp litespeed-purge all --allow-root`

WP Rocket (premium, plug-and-play):

1. Settings > WP Rocket > zakładka Dashboard
2. Clear and Preload Cache – wyczyści i od razu zacznie regenerować
3. CLI: `wp rocket clean --confirm --allow-root`

W3 Total Cache (mocno konfigurowalny, ale ciężki w obsłudze):

1. Performance > Dashboard > empty all caches
2. Lub konkretne: Page Cache, Database Cache, Object Cache, Minify

Jeśli używasz LiteSpeed na rekomendowanym przeze mnie CyberFolks – plugin LSCache jest darmowy i optymalnie skonfigurowany pod ich serwery. Sam crawler do wstępnego rozgrzania cache działa po stronie hostingu, więc po flush strona od razu odbudowuje wersje cached.

Uwaga na automatyczne purge po publikacji wpisu. Każdy z tych pluginów ma sekcję typu Auto Purge Rules – warto włączyć purge nie tylko edytowanego wpisu, ale też powiązanych archiwów (kategorii, tagów, strony głównej). Bez tego edytujesz wpis, ale na blogu listing wisi w starej wersji.

Więcej o doborze i konfiguracji wtyczek: problemy z wtyczkami WordPress.

Plugin cache wyczyszczony, a strona wciąż stara? Czas zejść głębiej. Server cache działa zanim PHP w ogóle dostanie szansę odpalić twoje wtyczki.

OPcache to bytecode cache PHP. Trzyma skompilowane wersje plików .php w pamięci. Jeśli zmieniłeś plik motywu lub plugin, a strona pokazuje stary kod, zwykle winien jest właśnie OPcache.

Flush:

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm

# Lub przez wp-cli plugin
wp opcache reset --allow-root

Na shared hostingu zwykle nie masz dostępu do `systemctl`. Dobry hosting (np. CyberFolks) udostępnia przycisk Restart PHP w panelu klienta. Słabe hostingi typu nazwa.pl czy home.pl wymagają zgłoszenia do supportu, co potrafi trwać godziny.

Varnish Cache to reverse proxy, który stoi przed Apache lub Nginx. Sprawdzasz obecność: `curl -I` powinien zwrócić nagłówek `Via: 1.1 varnish`.

Flush:

varnishadm 'ban req.url ~ .*'
# Lub konkretny URL:
varnishadm 'ban req.url == /produkt/buty/'

Wiele wtyczek (LiteSpeed, WP Rocket, W3TC) ma integrację z Varnish – po wpisaniu w ustawieniach IP serwera Varnish flush plugin automatycznie woła ban.

FastCGI Cache (Nginx) – jeśli twój serwer to Nginx z FastCGI cache, czyszczenie wymaga usunięcia plików z katalogu cache:

rm -rf /var/cache/nginx/fastcgi/*
nginx -s reload

Na hostingach zarządzanych zwykle tym zajmuje się panel (CloudPanel, Plesk, cPanel) – szukaj opcji Clear Cache. Jeśli masz wątpliwości co do konfiguracji serwera, zerknij na problemy z hostingiem WordPress – tam jest checklist diagnostyki.

CDN to ostatni bastion cache. Działa najdalej od ciebie – na setkach serwerów edge na całym świecie. Jeśli ustawiłeś agresywne reguły typu Cache Everything, Cloudflare może trzymać twoją stronę przez tygodnie, niezależnie od tego, co dzieje się na origin.

Cloudflare – metody purge:

1. Purge Everything – Caching > Configuration > Purge Everything. Atomowa opcja, czyści wszystko. Używaj rozważnie, bo CDN będzie musiał ponownie pobrać każdy zasób z origin.
2. Custom Purge – możesz wpisać konkretne URL-e (do 30 jednocześnie na bezpłatnym planie).
3. Wildcard Purge (Enterprise) – purge po wzorcu, np. `https://twojadomena.pl/produkt/*`.
4. Cache Tags (Enterprise) – purge po tagach przypiętych do zasobów.

Dla większości stron wystarczy plugin Cloudflare for WordPress lub integracja w LiteSpeed Cache – po publikacji wpisu plugin sam wywołuje API Cloudflare i czyści powiązane URL-e. Jeśli jeszcze nie masz Cloudflare, zacznij od jak zainstalować Cloudflare w WordPress.

BunnyCDN – w panelu Pull Zone > Purge Cache, można per URL lub całą strefę.

Kluczowa pułapka: Cloudflare Cache Everything Page Rule. Jeśli włączysz Cache Everything dla `*twojadomena.pl/*`, Cloudflare zacznie cachować HTML łącznie z koszykiem WooCommerce, panelem klienta, a nawet stronami logowania. Klienci zobaczą cudzy koszyk. Zawsze dodaj reguły Bypass dla:

• `/wp-admin/*`
• `/wp-login.php`
• `/cart/`, `/checkout/`, `/my-account/`
• URL-e z parametrami sesji

Na pewnym etapie warto rozważyć Cache Reserve lub Tiered Caching – ale to już dla dużych sklepów.

Page cache (LiteSpeed, WP Rocket) cachuje gotowe strony HTML. Redis Object Cache cachuje coś zupełnie innego – wyniki zapytań do bazy danych. Każde `wp_query`, `get_option`, `get_user_meta` zamiast lecieć do MySQL trafia do błyskawicznego Redisa w pamięci RAM.

Działa świetnie do momentu, kiedy nie zaczyna serwować przestarzałych danych. Klasyczne objawy: zmieniasz opcję w ustawieniach, ale w panelu admina nadal stara wartość. Albo dodajesz produkt, ale liczba w archiwum kategorii się nie aktualizuje.

Diagnostyka Redis:

# Czy Redis działa?
redis-cli ping
# Powinno zwrócić: PONG

# Sprawdz statystyki
redis-cli info stats

# Liczba kluczy
redis-cli dbsize

Flush Redis dla WordPressa:

# Najlepiej przez wp-cli (czyści tylko klucze WP, nie inne aplikacje)
wp redis flush --allow-root

# Albo brutalnie cały Redis
redis-cli FLUSHALL

Na CyberFolks Redis jest dostępny one-click w panelu i automatycznie zintegrowany z pluginem Redis Object Cache. Po prostu instalujesz wtyczkę Redis Object Cache, klikasz Enable Object Cache i działa.

Uwaga na shared hostingach: jeśli kilka stron dzieli ten sam Redis bez prefixów, FLUSHALL wyczyści cache wszystkich. Dlatego zawsze wp-cli `wp redis flush` – ta komenda czyści tylko klucze należące do twojej instalacji WP.

Optymalna konfiguracja: w `wp-config.php` ustaw unikalny prefix:

define('WP_CACHE_KEY_SALT', 'twojadomena_pl_');

Wtedy nawet FLUSHDB nie naruszy cache sąsiada. Więcej o problemach z bazą i Redisem: problemy z bazą danych WordPress.

Wyłączenie cache rozwiąże wszystkie problemy ze stale content – ale wywali ci wydajność strony do piwnicy. Sztuka polega na tym, żeby cache hit ratio (procent requestów obsłużonych z cache) był jak najwyższy, ale bez wpadek typu cached panel admina.

Co kontrolować:

1. Cache lifetime (TTL) – domyślnie 1-24h. Im dłużej, tym lepszy hit ratio, ale tym częściej widać stare treści po edycji. Auto-purge po publikacji wpisu rozwiązuje 90% przypadków.
2. Exclusion rules – URL-e, których nie należy cachować. Standardowo:
- `/wp-admin/`
- `/wp-login.php`
- `/cart/`, `/checkout/`, `/my-account/` (WooCommerce)
- `?add-to-cart=*`
- `/wp-json/*` (REST API)
3. Cookies that bypass cache – jeśli ciasteczko jest obecne, nie serwuj cache. Standardowo:
- `wordpress_logged_in_*` (zalogowani userzy)
- `woocommerce_items_in_cart`
- `woocommerce_cart_hash`
- `comment_author_*`
4. Mobile vs Desktop separate cache – jeśli masz osobny szablon mobilny, włącz separate cache file dla user-agent mobile.
5. Lazy load plus cache – obrazki lazy loaded mogą być cached razem ze stroną, ale dynamiczne placeholdery (np. liczniki) wymagają fragment caching lub AJAX.

Gdzie sprawdzić hit ratio:

• LiteSpeed Cache > Toolbox > View .htaccess plus wbudowany dashboard
• WP Rocket > Tools > Cache statistics
• Cloudflare > Analytics > Cached vs Uncached requests
• Varnish > `varnishstat`

Dobry cel: >80% hit ratio dla strony content. W sklepie WooCommerce realniej 50-70%, bo koszyk i checkout zawsze bypass. Jeśli twoja strona długo się ładuje mimo cache, sprawdź też wolny WordPress – jak przyspieszyć.

WooCommerce to najczęstsza ofiara źle skonfigurowanego cache. Klient widzi cudzy koszyk, ceny się nie odświeżają po zmianie waluty, kupon znika po dodaniu produktu. 99% tych problemów to brak prawidłowej konfiguracji wykluczeń.

Obowiązkowe wykluczenia URL-i:

• `/cart/` (lub `/koszyk/`)
• `/checkout/` (lub `/zamowienie/`)
• `/my-account/` (lub `/moje-konto/`)
• `/?add-to-cart=*`
• `/?wc-ajax=*`

Obowiązkowe cookies bypass:

• `woocommerce_cart_hash`
• `woocommerce_items_in_cart`
• `wp_woocommerce_session_*`
• `wordpress_logged_in_*`

Mini-koszyk w nagłówku – klasyczna pułapka. Mini-koszyk jest częścią cached HTML strony, więc każdy odwiedzający widzi ten sam stan. Rozwiązanie:

• AJAX cart fragments (domyślnie WooCommerce, ale niektóre cache wyłączają)
• Lub dedykowany endpoint REST API ładowany po stronie klienta

Cloudflare i WooCommerce – jeśli używasz Cache Everything, musisz dodać Page Rule Bypass dla wymienionych wyżej ścieżek. Inaczej klient A zobaczy koszyk klienta B. Realne ryzyko RODO.

LiteSpeed dla WooCommerce – plugin LiteSpeed ma dedykowaną sekcję ESI (Edge Side Includes) dla WooCommerce. Po włączeniu mini-koszyk, cena netto/brutto, waluta są renderowane jako oddzielne fragmenty wykluczone z cache, podczas gdy reszta strony nadal jest cached. Najlepsze rozwiązanie wydajnościowe dla sklepów na hostingu LiteSpeed.

Dla głębszej analizy WooCommerce check: problemy WooCommerce i WooCommerce wolno działa.

Prowadzisz sklep i nie wiesz, czy konfiguracja jest poprawna? Zadzwoń na +48 604 939 140 – sprawdzimy konfigurację cache i wykluczenia w 30 minut. Albo wypełnij formularz kontaktowy.

Po setkach diagnostyk klientów wyłapałem powtarzające się błędy. Oto top 8, które powodują 80% problemów.

1. Cached panel admina. Brak wykluczenia `/wp-admin/` lub `wordpress_logged_in_*` cookie. Skutek: panel ładuje się szybko, ale każda zmiana wymaga F5. Czasem widzisz cudzy panel.

2. Mini-koszyk stale. Brak ESI lub AJAX fragments dla mini-koszyka w headerze. Klient dodaje produkt, ale ikonka koszyka nadal pokazuje 0.

3. Session cookie cached. Cache plugin cachuje stronę z konkretnym wp_session lub PHPSESSID w nagłówkach. Drugi user dostaje cudzą sesję. Krytyczny problem RODO.

4. Brak auto-purge dla custom post types. Wpisy WordPress purge'ują się automatycznie, ale produkty WooCommerce, custom post types z ACF czy CPT UI – nie zawsze. Trzeba dodać hooki:

add_action('save_post_product', function($post_id) {
    do_action('litespeed_purge_post', $post_id);
});

5. Cache Everything Cloudflare bez wykluczeń. Klasyczne strzelenie sobie w stopę. Konfiguracja wymaga minimum 4-5 Page Rules Bypass.

6. OPcache trzyma stary kod po deploy. Po wgraniu nowych plików .php przez FTP/SSH, OPcache wciąż serwuje skompilowaną starą wersję. Dlatego deploy zawsze powinien kończyć się `service php-fpm reload` lub `wp opcache reset`.

7. Konflikt dwóch pluginów cache jednocześnie. WP Rocket plus W3TC plus LiteSpeed – nie. Wybierz jeden. Drugi tylko psuje. Więcej o konfliktach: biały ekran śmierci WordPress.

8. Service Worker browser cache. Niektóre PWA pluginy instalują Service Worker, który cachuje HTML w przeglądarce na tygodnie. User musi sam czyścić Application > Clear Storage w DevTools. Rozwiązanie: kontrolowana wersja SW i cache strategy network-first.

Lista wykluczeń różni się dla każdego sklepu. Jeśli masz nietypowy use case (membership site, multi-vendor marketplace, b2b z cenami zalogowanego), warto skonsultować konfigurację z kimś, kto już to robił.

Pytanie zadawane częściej niż jakiekolwiek inne. Krótka odpowiedź zależy od twojego hostingu.

LiteSpeed Cache (FREE) – jeśli masz hosting LiteSpeed lub OpenLiteSpeed. Najlepszy darmowy plugin na rynku. Pełna integracja z LSCache na poziomie serwera (cache trafia do RAM serwera, a nie do dysku jak inne wtyczki), Image Optimization w cenie, ESI dla WooCommerce, integracja Cloudflare. Działa tylko na hostingach LiteSpeed – m.in. CyberFolks, LH.pl, Zenbox.

WP Rocket (~50 USD/rok) – jeśli masz Apache lub Nginx i nie chcesz konfigurować. Plug-and-play. Włączasz, działa. Szybkie wsparcie, regularne aktualizacje, dobre dla osób nietechnicznych. Nie ma Image Optimization w cenie (osobno, Imagify), brak integracji ESI z WooCommerce.

W3 Total Cache (FREE/PRO) – dla zaawansowanych. Najwięcej opcji, ale też najbardziej skomplikowany. Łatwo coś zepsuć. Polecam tylko jeśli wiesz, co robisz.

WP Super Cache (FREE) – stary, prosty, nadal działa. Brak nowoczesnych funkcji typu Critical CSS, ale stabilny i lekki.

Porównanie:

Moja rekomendacja na 2026:

• Nowy sklep lub blog: CyberFolks plus LiteSpeed Cache (FREE)
• Istniejąca strona na zwykłym Nginx/Apache: WP Rocket (oszczędza godziny konfiguracji)
• Duży portal z dedykowanym devopsem: W3 Total Cache plus Varnish plus Redis

Niezależnie od wyboru – nie instaluj dwóch jednocześnie. Konflikty są gwarantowane.

Potrzebujesz audytu konfiguracji cache albo migracji ze słabego hostingu na taki, który ogarnie cache za ciebie? Skontaktuj się z nami lub zadzwoń +48 604 939 140. Robimy strony internetowe i sklepy WooCommerce z prawidłowo skonfigurowanym cache od dnia uruchomienia. Sprawdź też migracja WordPress na nowy hosting jeśli planujesz przeprowadzkę.

Wiele z tych problemów można rozwiązać samodzielnie – ale gdy brakuje czasu, narzędzi lub utknąłeś na etapie diagnozy, warto zlecić pracę zespołowi który robi to codziennie. W KC Mobile zajmujemy się tym od lat.

Zobacz powiązane usługi i materiały:

• wdrożenie WordPress
• strona na WordPressie
• najlepszy hosting WordPress
• PHP memory limit WordPress
• biały ekran śmierci (WSOD)

Jeśli opis w tym wpisie nie dotyczy dokładnie Twojej sytuacji, napisz do nas – odpowiadamy w ciągu 24 godzin roboczych.