Cache w WordPress – page cache, object cache, edge cache i Speculative Loading w praktyce
Opublikowano: 20 maja 2026 · Autor: Marcin Szewczyk-Wilgan
Typowa strona WordPress wykonuje od 50 do 200 zapytań do bazy danych przy każdym załadowaniu. Sklep WooCommerce z rozbudowanym katalogiem potrafi przekroczyć 500 zapytań na odsłonę. Bez cachowania każde z tych zapytań trafia bezpośrednio do MySQL, co przekłada się na czas odpowiedzi serwera (TTFB), wyniki Core Web Vitals i pozycje w wyszukiwarce. Cache to nie jedna technologia, lecz zestaw warstw, z których każda rozwiązuje inny problem. Włączenie wtyczki cache bez zrozumienia tych warstw daje w najlepszym razie połowiczne efekty, a w najgorszym generuje trudne do zdiagnozowania konflikty. Ten artykuł opisuje wszystkie warstwy cachowania dostępne w ekosystemie WordPress, wyjaśnia, kiedy i dlaczego każda z nich ma sens, i pokazuje, jak je diagnostykować.
Warstwy cache w WordPress od serwera do przeglądarki
Cache w WordPressie to stos kilku niezależnych mechanizmów. Każdy działa na innym poziomie i rozwiązuje inny wąski punkt wydajnościowy. Zrozumienie, co robi każda warstwa, pozwala dobrać strategię cachowania do konkretnej strony zamiast stosować uniwersalne recepty.
opcache.memory_consumption do liczby plików PHP na serwerze. To fundament, na którym opierają się pozostałe warstwy.
Cache-Control i Expires. Przy kolejnej wizycie przeglądarka nie pobiera ponownie CSS, JS i obrazów. Najskuteczniejsza warstwa dla powracających użytkowników, ale nie przyspiesza pierwszej wizyty.
Object cache: Redis vs Memcached
Object cache to warstwa, która robi największą różnicę na stronach z zalogowanymi użytkownikami, rozbudowanymi panelami administracyjnymi i sklepami WooCommerce. Page cache obsługuje ruch anonimowy, ale nie pomaga tam, gdzie treść jest dynamiczna. Wtyczka object cache (np. Redis Object Cache, Object Cache Pro) nie dostarcza samego Redis, lecz łączy WordPressa z serwerem Redis zainstalowanym na hoście. Bez Redis lub Memcached na serwerze żadna wtyczka nie zapewni trwałego object cache.
Trwałość, struktury danych i replikacja
Redis oferuje trwałość danych (RDB/AOF), co oznacza, że cache przeżywa restart serwera i nie trzeba go odbudowywać od zera. Obsługuje złożone struktury (hash, sorted set, list), co pozwala np. aktualizować pojedyncze pole bez pobierania całego obiektu. Wspiera replikację i klasteryzację (Redis Sentinel, Redis Cluster) dla środowisk z wysoką dostępnością. WordPress Site Health od wersji 6.1 aktywnie rekomenduje persistent object cache, a Redis jest domyślnym wyborem większości managed hostingów.
Prostota i szybkość dla prostych kluczy
Memcached jest wielowątkowy i w testach syntetycznych bywa nieco szybszy od Redis przy prostych operacjach GET/SET na wielu rdzeniach. Jest prostszy w konfiguracji i zużywa mniej pamięci na klucz. Główna wada: brak trwałości. Po restarcie serwera cały cache jest pusty, co generuje chwilowy skok obciążenia bazy danych (tzw. stampede). Dla WordPress wybór Memcached ma sens, gdy hosting nie oferuje Redis, lub na stronach z bardzo prostymi wzorcami dostępu do danych.
Praktyczne wskazówki
Jeśli PHP i Redis działają na tym samym serwerze, używaj gniazda Unix (Unix socket) zamiast TCP, co eliminuje narzut sieciowy. Ustaw politykę ewikacji na volatile-lru, by Redis usuwał najstarsze klucze z ustawionym TTL, a nie losowe dane. W instalacjach multisite przydzielaj oddzielne prefiksy kluczy per strona. W wp-config.php definiuj WP_REDIS_HOST, WP_REDIS_PORT (lub WP_REDIS_PATH dla socketa) i unikalny WP_CACHE_KEY_SALT.
Nie każda strona potrzebuje object cache
Prosta strona firmowa bez logowania, z kilkuset odsłonami dziennie, zyska więcej z prawidłowo skonfigurowanego page cache niż z Redis. Object cache przyspiesza panel administracyjny, ale jeśli administratorem jest jedna osoba, efekt jest minimalny. Na tanim hostingu współdzielonym Redis zwykle nie jest dostępny, a instalowanie go samodzielnie mija się z celem. Koncentruj się na page cache i optymalizacji bazy danych.
Page cache: wtyczkowy, serwerowy i różnica, która ma znaczenie
Page cache to warstwa o największym wpływie na TTFB dla niezalogowanych użytkowników. Eliminuje cały stos WordPress (PHP, MySQL, motywy, wtyczki) i serwuje gotowy HTML. Może działać na dwóch poziomach, które różnią się zasadniczo pod względem wydajności.
CDN i edge cache: cachowanie bliżej użytkownika
Page cache i object cache rozwiązują problem generowania odpowiedzi na serwerze origin. CDN rozwiązuje problem dostarczenia tej odpowiedzi do użytkownika. Jeśli serwer stoi w Niemczech, a użytkownik łączy się z Australii, fizyczna odległość dodaje 200 do 400 ms latencji niezależnie od tego, jak szybki jest serwer. CDN eliminuje ten problem, serwując treść z najbliższego punktu edge.
Pliki statyczne na serwerach brzegowych
Podstawowa konfiguracja CDN dystrybuuje pliki CSS, JavaScript, obrazy i fonty. Serwer origin nadal generuje HTML. To standard, który powinien działać na każdej stronie WordPress. Konfiguracja polega na wskazaniu CDN jako źródła zasobów statycznych (przez wtyczkę lub zmianę URL w konfiguracji motywu). Zmniejsza obciążenie serwera origin i przyspiesza ładowanie zasobów.
Pełne strony HTML na edge
Cloudflare APO (Automatic Platform Optimization) cachuje pełne strony WordPress na serwerach edge, nie tylko zasoby statyczne. Oznacza to, że żądanie HTML nie trafia do serwera origin w ogóle. Dla stron z międzynarodowym ruchem to zmiana jakościowa: TTFB poniżej 100 ms niezależnie od lokalizacji użytkownika. APO automatycznie invaliduje cache przy zmianach w WordPressie i obsługuje dynamiczne nagłówki (cookies, nonce).
Kiedy edge cache nie wystarczy
Strony z bardzo częstą publikacją (kilka razy dziennie) mogą mieć problem z aktualnością cache na edge, bo propagacja invalidacji między punktami PoP wymaga czasu. Strony z zalogowanymi użytkownikami (WooCommerce, fora, LMS) nie korzystają z full-page edge cache dla sesji zalogowanych. Dynamiczne treści wymagają rozwiązań hybrydowych: edge cache dla anonimowych odwiedzających, object cache i page cache serwerowy dla reszty.
Speculative Loading: najnowsza warstwa w stosie cache WordPress
WordPress 6.8 wprowadził natywne wsparcie dla Speculation Rules API, co jest jedną z najważniejszych zmian wydajnościowych ostatnich lat. To warstwa, która działa po stronie przeglądarki i nie obciąża serwera. Jej zadaniem jest skrócenie postrzeganego czasu ładowania stron wewnętrznych do niemal zera.
wp_speculation_rules_configuration w functions.php lub przez dedykowaną wtyczkę Speculative Loading, która udostępnia interfejs w Ustawieniach. Speculative Loading działa domyślnie tylko dla niezalogowanych użytkowników, co jest rozsądne, bo strony dynamiczne nie są dobrymi kandydatami do prerenderingu.
rel="nofollow". Możesz dodać własne wykluczenia (np. koszyk, checkout, strony z formularzami) przez filtr plsr_speculation_rules_href_exclude_paths lub dodanie klasy CSS no-prerender do wybranych linków.
Dobór strategii cache do typu strony
Nie istnieje uniwersalna konfiguracja cache. Strona firmowa, blog, sklep WooCommerce i portal z logowaniem mają fundamentalnie różne wzorce ruchu i różne wąskie gardła. Poniżej przedstawiamy rekomendacje oparte na doświadczeniach z wielu wdrożeń w ramach opieki WordPress w WebOptimo.
Page cache + CDN + Speculative Loading
Ruch głównie anonimowy, rzadkie aktualizacje treści. Page cache (najlepiej serwerowy) eliminuje PHP. CDN skraca latencję dla odległych użytkowników. Speculative Loading (prerender, moderate) daje natychmiastowe przejścia między podstronami. Object cache opcjonalny, bo jedynym zalogowanym użytkownikiem jest administrator. OPcache obowiązkowy. Typowy TTFB: poniżej 100 ms.
Page cache + CDN + Object cache + Speculative Loading
Częstsze publikacje wymagają sprawnej invalidacji cache. Object cache przyspiesza generowanie nowych stron i panel administracyjny przy dużej liczbie postów. CDN z pełnym edge cache (Cloudflare APO) jest tu szczególnie wartościowy, bo ruch jest globalny i głównie anonimowy. Speculative Loading działa świetnie na stronach z dużą liczbą linków wewnętrznych (posty powiązane, kategorie).
Page cache + Object cache (Redis) + CDN + selektywne wykluczenia
WooCommerce to najbardziej wymagający scenariusz. Katalog produktów korzysta z page cache, ale koszyk, checkout, panel klienta i strony z dynamicznymi cenami muszą być wykluczone. Redis jest tu niezbędny, bo przyspiesza setki zapytań związanych z sesjami, wariantami produktów i stanami magazynowymi. Speculative Loading z wykluczeniem koszyka i checkoutu. Edge cache dla stron produktowych, ale nie dla sesji zalogowanych.
Object cache (Redis) + fragment cache + ograniczony page cache
Większość ruchu to zalogowani użytkownicy, więc page cache ma ograniczone zastosowanie. Redis object cache to główna warstwa wydajnościowa. Fragment caching (ESI w Varnish, AJAX lazy load) pozwala cachować części strony, które są wspólne dla użytkowników, i ładować dynamicznie tylko spersonalizowane elementy. Page cache działa wyłącznie dla stron publicznych (landing page, cennik, blog). TTFB zależy głównie od konfiguracji PHP-FPM i Redis.
Diagnostyka: jak sprawdzić, czy cache działa
Włączenie cache bez weryfikacji, czy faktycznie działa, to częsty błąd. Poniższe narzędzia i metody pozwalają potwierdzić, że każda warstwa cache funkcjonuje prawidłowo i faktycznie poprawia wydajność.
X-FastCGI-Cache: HIT oznacza trafienie w cache Nginx. CF-Cache-Status: HIT to trafienie w Cloudflare. X-Cache: HIT pojawia się w wielu konfiguracjach CDN. Wartość MISS oznacza, że cache nie został trafiony i strona była generowana od nowa. Sprawdzaj nagłówki poleceniem curl -I lub w zakładce Network narzędzi deweloperskich przeglądarki.
redis-cli MONITOR pokazuje w czasie rzeczywistym wszystkie operacje na Redis. Pozwala zobaczyć, czy WordPress rzeczywiście zapisuje i odczytuje dane z cache. redis-cli INFO stats podaje stosunek trafień do chybień (keyspace_hits vs keyspace_misses). Zdrowy cache powinien mieć hit ratio powyżej 85%. Niższy stosunek sugeruje zbyt małą ilość pamięci lub zbyt agresywną politykę ewikacji.
<script type="speculationrules"> w źródle strony.
curl -w "%{time_starttransfer}".
Podsumowanie
Cache w WordPress to nie pojedynczy przełącznik, lecz stos warstw, z których każda odpowiada za inny etap dostarczania strony. OPcache przyspiesza kompilację PHP. Object cache (Redis, Memcached) odciąża bazę danych. Page cache eliminuje przetwarzanie WordPress dla anonimowego ruchu. CDN skraca odległość fizyczną do użytkownika. Browser cache oszczędza ponowne pobieranie zasobów. Speculative Loading sprawia, że przejścia między stronami są postrzegane jako natychmiastowe. Żadna z tych warstw nie zastępuje pozostałych. Ich siła leży w kombinacji dobranej do typu strony, wzorców ruchu i infrastruktury hostingowej.
W WebOptimo konfiguracja stosu cache jest częścią każdego wdrożenia i planu opieki WordPress. Dobieramy warstwy do konkretnej strony, monitorujemy hit ratio i TTFB, i optymalizujemy konfigurację w miarę zmian w ruchu i treściach. Jeśli Twoja strona jest wolna mimo zainstalowanej wtyczki cache, skontaktuj się z nami po diagnostykę i konfigurację, która naprawdę działa.
Najczęstsze pytania o cache w WordPress
Page cache zapisuje gotowy HTML i serwuje go bez uruchamiania PHP. Działa dla niezalogowanych użytkowników. Object cache (Redis, Memcached) zapisuje wyniki zapytań do bazy w RAM i przyspiesza strony dynamiczne, panel administracyjny i ruch zalogowanych użytkowników. Obie warstwy się uzupełniają.
Redis jest szczególnie wartościowy dla WooCommerce, forów i portali z logowaniem, gdzie page cache nie działa. Dla prostych stron firmowych bez logowania korzyści są mniejsze, choć Redis nadal przyspiesza panel administracyjny. WordPress Site Health aktywnie rekomenduje persistent object cache.
Redis jest lepszym wyborem w większości przypadków: oferuje trwałość danych, replikację i złożone struktury danych. Memcached jest prostszy i bywa szybszy przy prostych operacjach, ale traci cały cache po restarcie. W praktyce wybór często zależy od oferty dostawcy hostingu.
Mechanizm wbudowany w WordPress od wersji 6.8, oparty na Speculation Rules API. Pozwala przeglądarce wstępnie pobrać lub wyrenderować strony, na które użytkownik prawdopodobnie przejdzie. W trybie prerender z eagerness moderate testy wykazują redukcję LCP nawet o 98%. Działa w przeglądarkach Chromium.
Nie. Page cache generuje statyczny HTML na serwerze origin. CDN dystrybuuje go na serwery brzegowe bliżej użytkownika. Page cache bez CDN jest szybkie lokalnie, ale wolne na odległość. CDN bez page cache dystrybuuje dynamiczne odpowiedzi z ograniczoną korzyścią. Najskuteczniejsza jest kombinacja obu warstw.
Zainstaluj Query Monitor, by zobaczyć liczbę zapytań i status object cache. Sprawdź nagłówki HTTP (X-Cache, CF-Cache-Status) poleceniem curl lub w narzędziach deweloperskich przeglądarki. Dla Redis użyj redis-cli INFO stats i sprawdź hit ratio (powinno być powyżej 85%). TTFB poniżej 200 ms dla cachowanych stron to dobry punkt odniesienia.
