Redis Object Cache - przyspieszenie WordPress

Object cache to mechanizm, który zapisuje w pamięci wynik kosztownych zapytań do bazy danych, żeby WordPress nie musiał liczyć tego samego przy każdym wejściu na stronę. WordPress ma wbudowaną klasę WP_Object_Cache, ale domyślnie działa ona tylko w obrębie jednego requestu (non-persistent) – po wyrenderowaniu strony cache znika.

Praktyczny efekt jest taki: te same dane (opcje motywu, meta postów, wyniki WP_Query) są pobierane z MySQL od nowa przy każdym kliknięciu użytkownika. Przy małym blogu to nieistotne. Przy WooCommerce z setkami produktów i wieloma zalogowanymi klientami baza staje się wąskim gardłem.

Redis zmienia regułę gry, bo zamienia ten ulotny cache w trwały (persistent). Pierwszy request odpytuje MySQL i zapisuje wynik w pamięci RAM serwera, a każdy kolejny request – także od innego użytkownika – odczytuje gotową wartość z Redis w mikrosekundach. Bazę odciążamy, a czas generowania strony (TTFB) spada.

To częste źródło nieporozumień, bo w WordPress funkcjonują trzy różne warstwy buforowania i łatwo je pomylić. Każda rozwiązuje inny problem, a Redis Object Cache obsługuje tylko jedną z nich.

Page cache (np. WP Super Cache, LiteSpeed, Varnish) zapisuje gotowy HTML i serwuje go z pominięciem PHP. Świetny dla anonimowych odwiedzających, ale bezużyteczny dla zalogowanych użytkowników i koszyka WooCommerce, bo te strony muszą być dynamiczne. Tu wchodzi object cache – działa właśnie tam, gdzie page cache zawodzi.

Transients API to natywny mechanizm WordPress do trwałego przechowywania danych. Problem w tym, że bez persistent object cache transienty lądują w tabeli wp_options w MySQL, czyli dokładnie tam, którą chcemy odciążyć. Po podłączeniu Redis transienty automatycznie trafiają do pamięci, a tabela wp_options przestaje puchnąć.

Redis przyspiesza stronę proporcjonalnie do liczby kosztownych zapytań, które WordPress wykonuje przy każdym ładowaniu. Im więcej powtarzalnych odwołań do bazy, tym większy zysk. Dlatego nie ma sensu instalować go odruchowo na każdej witrynie.

Największe korzyści zobaczysz tam, gdzie baza pracuje ciężko: WooCommerce, multisite, strony z rozbudowanymi polami ACF, agregatory i serwisy z dużym ruchem zalogowanych użytkowników. W takich przypadkach widzieliśmy spadek liczby zapytań SQL na request z kilkuset do kilkudziesięciu.

Na prostym blogu firmowym albo wizytówce z dobrym page cache Redis nie da odczuwalnej różnicy – HTML i tak serwowany jest z gotowego pliku, a baza prawie nie pracuje. Dodatkowy komponent to wtedy więcej do utrzymania bez realnego zysku.

Pełne wdrożenie to dwa etapy: uruchomienie usługi Redis na serwerze oraz podpięcie jej wtyczką w WordPress. Na hostingu współdzielonym pierwszy etap zwykle robi za Ciebie dostawca, na VPS musisz zainstalować Redis samodzielnie.

Na własnym serwerze (Ubuntu/Debian) instalacja i test wyglądają tak:

sudo apt update && sudo apt install redis-server
sudo systemctl enable --now redis-server
redis-cli ping   # poprawna odpowiedz: PONG

W WordPress instalujesz wtyczkę Redis Object Cache (rhubarbgroup, repozytorium WordPress.org), a następnie w zakładce Ustawienia > Redis klikasz Enable Object Cache. Wtyczka tworzy plik object-cache.php w wp-content i od tej chwili WordPress używa Redis jako backendu.

Jeśli Redis nasłuchuje pod niestandardowym hostem, portem lub wymaga hasła, dopisujesz dane w wp-config.php przed wierszem o zakończeniu edycji:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'twoje-haslo');
define('WP_REDIS_PREFIX', 'site1_'); // unikalny prefix per witryna

Prefiks jest kluczowy przy wielu stronach na jednej instancji Redis – bez niego witryny nadpisują sobie nawzajem klucze. To jeden z najczęstszych błędów, jakie spotykamy przy migracjach. Dane dostępowe do Redis (host, port, hasło) na hostingu znajdziesz w panelu, a jego dostępność zależy od pakietu.

Sam status Connected we wtyczce to za mało – warto potwierdzić, że cache realnie przejmuje zapytania. Pierwszy sygnał znajdziesz w panelu wtyczki: status powinien pokazywać Connected, a hit ratio rosnąć powyżej 90 procent po kilku godzinach normalnego ruchu.

Twardy dowód daje wtyczka Query Monitor. W zakładce Object Cache zobaczysz liczbę trafień (hits) i pudeł (misses) oraz informację, czy persistent cache jest aktywny. Niski hit ratio przy wysokim ruchu zwykle oznacza zbyt mały limit pamięci albo agresywne czyszczenie cache.

Od strony serwera przydają się polecenia diagnostyczne:

redis-cli info stats   # statystyki trafien i braku trafien
redis-cli dbsize       # liczba kluczy w cache
wp cache flush         # czyszczenie cache przez WP-CLI

Dobrą praktyką jest też pomiar liczby zapytań do bazy przed i po. WordPress udostępnia funkcję get_num_queries() – tymczasowe wstawienie jej do stopki motywu pokaże realny spadek liczby zapytań SQL na stronę.

Warto wykonać taki pomiar na realnie obciążonym widoku, na przykład na karcie produktu WooCommerce lub stronie koszyka, a nie na pustej stronie głównej. Dopiero porównanie dwóch liczb – przed włączeniem Redis i po nim – mówi, czy wdrożenie miało sens i czy cache faktycznie przejmuje powtarzalne zapytania.

Dla WordPress rekomendujemy Redis, a nie Memcached. Oba trzymają dane w RAM w modelu klucz–wartość, ale Redis oferuje trwałość, lepszą autoryzację, bogatsze struktury danych i dojrzalszą wtyczkę z obsługą sesji WooCommerce. Memcached bywa nieznacznie szybszy przy bardzo prostym cache, lecz dla typowej witryny ta różnica jest niezauważalna.

Warto też ustawić rozsądny limit pamięci i politykę eksmisji w /etc/redis/redis.conf, żeby Redis nie zjadał całego RAM serwera:

maxmemory 256mb
maxmemory-policy allkeys-lru

Object cache to jeden z elementów wydajnych stron internetowych opartych na WordPress, obok page cache, optymalizacji obrazów i dobrego hostingu. Jeśli interesuje Cię odpowiedni serwer pod Redis, warto wybrać hosting z natywnym wsparciem, na przykład CyberFolks, gdzie Redis podłączysz z poziomu panelu.

W naszych wdrożeniach widzimy, że Redis nie jest magicznym przełącznikiem na każdą stronę – jego sens rośnie wraz z liczbą dynamicznych zapytań. Na sklepach WooCommerce i serwisach z rozbudowanymi polami ACF efekt bywa wyraźny, bo to właśnie tam MySQL pracuje najciężej.

Najczęstszy błąd, na jaki trafiamy podczas audytów, to Redis włączony bez prefiksu na kilku witrynach współdzielących jedną instancję – strony nadpisują sobie klucze i pojawiają się trudne do zdiagnozowania błędy. Drugi powtarzalny problem to brak limitu pamięci, przez co Redis rośnie aż do wyczerpania RAM. Dlatego po każdym wdrożeniu mierzymy hit ratio i liczbę zapytań SQL, zamiast zakładać, że samo włączenie wtyczki załatwiło sprawę.