Redis Object Cache w WordPress — kiedy przyspiesza, a kiedy nie ma sensu

WordPress bez cache'a odpytuje bazę MySQL przy każdym załadowaniu strony — nawet gdy dane się nie zmieniły. Na prostej stronie firmowej to nie problem: 10–20 zapytań SQL na request, baza odpowiada w milisekundach. Ale na WooCommerce z 500 produktami, ACF z 30 polami na podstronę i 10 wtyczkami robiącymi własne zapytania — MySQL dostaje 100–200 zapytań na każde załadowanie strony. I tu wchodzi Redis: przechowuje wyniki zapytań w pamięci RAM, żeby nie odpytywać bazy za każdym razem. Poniżej opisujemy, kiedy to realnie przyspiesza WordPress, a kiedy jest niepotrzebnym dodatkiem.

Co cache'uje Redis w WordPress

Redis Object Cache w WordPress (najczęściej przez wtyczkę Redis Object Cache autorstwa Till Krüss) zastępuje domyślny mechanizm WP Object Cache. Zamiast trzymać dane w pamięci PHP (która znika po zakończeniu requestu), Redis trzyma je w osobnym serwerze pamięciowym, który przeżywa między requestami.

Co konkretnie cache'uje:

• Wyniki zapytań do bazy — wpisy, strony, produkty WooCommerce, pola ACF, opcje (options table)
• Transients — tymczasowe dane wtyczek, które normalnie lądują w tabeli wp_options i spowalniają ją
• Sesje użytkowników — zamiast w bazie, sesje trzymane w RAM (szybsze logowanie, szybszy panel admina)
• Fragment cache — fragmenty stron, które nie zmieniają się między requestami

Efekt: baza MySQL dostaje 80–90% mniej zapytań, bo Redis odpowiada z pamięci w mikrosekundach zamiast milisekund. Na stronie firmowej różnica jest minimalna. Na sklepie WooCommerce z 500+ produktami i panelu admina z ACF — różnica jest dramatyczna.

Kiedy Redis ma sens — i kiedy nie

Mamy prostą regułę: Redis ma sens, gdy WordPress wykonuje powyżej 50 zapytań SQL na request. Poniżej tego progu zwykły page cache (WP Super Cache, W3 Total Cache) wystarczy i jest prostszy.

Redis ma sens w tych scenariuszach:

• WooCommerce z dużym katalogiem — strony produktowe generują 80–150 zapytań SQL (produkt + warianty + cross-sells + powiązane + recenzje)
• Strony z ACF — każde pole ACF to osobne zapytanie do wp_postmeta. 30 pól na podstronę = 30 dodatkowych zapytań
• Panel admina — WordPress admin jest dynamiczny i nie podlega page cache. Redis przyspiesza panel 2–3x
• Strony z wieloma wtyczkami — każda wtyczka dodaje własne zapytania. 10 wtyczek = 50–100 dodatkowych zapytań

Redis NIE ma sensu, gdy: strona jest statyczna (kilka podstron, bez dynamicznych danych), masz page cache, który serwuje gotowy HTML (wtedy baza nie jest odpytywana wcale), albo hosting nie wspiera Redis (współdzielony hosting zwykle nie ma Redis).

Wdrożenie — krok po kroku

Wdrożenie Redis na VPS/dedykowanym serwerze:

• Zainstaluj Redis na serwerze: apt install redis-server (Debian/Ubuntu)
• Ustaw Redis do nasłuchiwania tylko na localhost: bind 127.0.0.1 w /etc/redis/redis.conf
• Dodaj define('WP_REDIS_HOST', '127.0.0.1'); do wp-config.php
• Zainstaluj wtyczkę Redis Object Cache i włącz object cache w ustawieniach
• Sprawdź w zakładce Diagnostics, czy połączenie działa

Cała operacja zajmuje 15–30 minut. Największe ryzyko: konflikty z innymi wtyczkami cache'ującymi. Dlatego przed wdrożeniem Redis wyłączamy inne mechanizmy object cache (nie page cache — Redis i page cache pracują razem).

Pomiar TTFB — jak sprawdzić, czy Redis działa

TTFB (Time to First Byte) to metryka, która najlepiej pokazuje efekt Redis. Mierzę ją przed i po wdrożeniu na trzech typach stron: strona główna, strona produktowa WooCommerce i panel admina.

Typowe wyniki z naszych wdrożeń:

• Strona główna — TTFB z 400–600 ms do 150–250 ms (z page cache różnica mniejsza, bo page cache omija PHP)
• Strona produktowa — TTFB z 800–1200 ms do 300–500 ms (tu największy efekt, bo produkty mają dużo zapytań)
• Panel admina — ładowanie dashboardu z 3–5s do 1–2s (brak page cache = Redis robi całą robotę)

Do pomiaru używamy curl z opcją -w "%{time_starttransfer}" lub WebPageTest (pole „First Byte"). Lighthouse TTFB jest mniej wiarygodne, bo mierzy z lab, nie z produkcji.

Błędy, które widzimy przy wdrożeniach

Trzy najczęstsze problemy z Redis na WordPressie:

• Redis bez limitu pamięci — domyślnie Redis zjada RAM bez limitu. Na serwerze z 2 GB RAM może zabić inne procesy. Ustawiamy maxmemory 256mb i maxmemory-policy allkeys-lru.
• Stary cache po zmianach — klient zmienia cenę produktu, ale na froncie widzi starą. Rozwiązanie: flush cache po zapisie (wp cache flush) albo konfiguracja TTL (czas życia cache).
• Konflikty z innymi wtyczkami cache — LiteSpeed Cache, W3 Total Cache i inne mają własne mechanizmy object cache. Dwa object cache naraz = błędy. Zostaw page cache, wyłącz object cache z wtyczki.

Redis to prosta technologia, ale wymaga poprawnej konfiguracji. Jeśli potrzebujesz pomocy z optymalizacją wydajności WordPress — wdrażamy Redis w ramach kompleksowej optymalizacji.