Cache obiektowy przechowuje wyniki wybranych operacji WordPressa w pamięci podręcznej. Redis może być używany jako mechanizm takiej pamięci podręcznej.
Przyspieszenie jest widoczne wtedy, gdy strona często wykonuje te same zapytania do bazy danych albo powtarza kosztowne operacje po stronie PHP. W takiej sytuacji WordPress może skorzystać z wcześniej zapisanych danych zamiast wykonywać te same operacje ponownie.
Spis treści
Jakie są ograniczenia w WooCommerce
Redis i cache obiektowy nie zastępują cache strony. Cache strony zapisuje gotowy wynik renderowania strony, a cache obiektowy dotyczy wybranych danych i operacji używanych przez WordPressa.
W WooCommerce trzeba rozróżnić dane, które można bezpiecznie zapisać w pamięci podręcznej, od danych, które muszą pozostać dynamiczne. Dotyczy to szczególnie koszyka i checkoutu, gdzie zawartość oraz stan zamówienia mogą zależeć od bieżącej sesji użytkownika.
Co to oznacza w praktyce
- Redis i cache obiektowy mogą pomóc przy dynamicznych stronach WordPressa, jeśli zmniejszają liczbę powtarzalnych zapytań do bazy danych.
- Nie należy traktować cache obiektowego jako zamiennika cache strony.
- W WooCommerce koszyk i checkout wymagają ostrożności, ponieważ część danych musi być zawsze aktualna i dynamiczna.
- Problemy z koszykiem lub checkoutem mogą wynikać z zapisania w pamięci podręcznej danych, które nie powinny być cache’owane.
Czym różni się cache strony od cache obiektowego
Cache strony zapisuje gotowy wynik wygenerowania strony, najczęściej jako HTML dla konkretnego adresu URL. Dzięki temu kolejna osoba może otrzymać gotową odpowiedź bez pełnego uruchamiania WordPressa, motywu i części wtyczek.
Cache strony najlepiej działa dla treści publicznych i takich samych dla wszystkich odwiedzających, na przykład wpisów, stron informacyjnych lub statycznych landing page. W WooCommerce trzeba stosować go ostrożnie, ponieważ koszyk, konto klienta, checkout i elementy zależne od sesji użytkownika nie powinny być traktowane jak zwykła statyczna strona.
Cache obiektowy zapisuje wybrane dane używane przez WordPressa podczas generowania strony. Mogą to być wyniki zapytań do bazy danych, opcje, fragmenty danych z wtyczek lub inne obiekty, do których WordPress odwołuje się wielokrotnie.
Redis jest mechanizmem używanym jako cache obiektowy. Przechowuje dane po stronie serwera, aby WordPress mógł szybciej odczytywać powtarzalne informacje bez wykonywania tych samych zapytań do bazy danych przy każdym żądaniu.
Cache strony i cache obiektowy – porównanie
| Obszar | Cache strony | Cache obiektowy z Redis |
|---|---|---|
| Co zapisuje | Gotowy HTML strony lub widoku | Dane używane przez WordPressa podczas generowania strony |
| Najlepsze zastosowanie | Publiczne strony o stałej treści | Dynamiczne WordPressy i sklepy z wieloma zapytaniami do bazy |
| Wpływ na WooCommerce | Wymaga wykluczeń dla koszyka, konta i checkoutu | Może przyspieszyć działanie bez zapisywania całej strony jako HTML |
| Typowe ryzyko | Pokazanie nieaktualnego lub cudzej sesji zależnego widoku | Nieaktualne dane, jeśli wtyczka lub integracja źle obsługuje cache |
Kiedy Redis może przyspieszyć WordPressa i WooCommerce
Redis pomaga szczególnie wtedy, gdy strona nie może w pełni korzystać z cache strony, ale nadal wykonuje wiele powtarzalnych operacji. Dotyczy to między innymi sklepów, paneli klienta, stron zalogowanych użytkowników, rozbudowanych filtrów produktów oraz dużych instalacji WordPressa z wieloma wtyczkami.
W WooCommerce wiele widoków jest dynamicznych. Koszyk, checkout i konto klienta zależą od sesji, cookies i bieżących danych zamówienia. Cache obiektowy może w takiej sytuacji zmniejszyć obciążenie bazy danych, jednocześnie pozostawiając sam widok dynamiczny.
Redis może być pomocny, gdy:
- strona ma dużo produktów, kategorii, atrybutów lub wariantów,
- wtyczki często odczytują opcje, metadane lub dane produktów,
- panel administracyjny WordPressa działa wolno przy codziennej pracy,
- checkout zwalnia w czasie większego ruchu,
- strona ma wielu zalogowanych użytkowników, dla których cache strony ma ograniczone zastosowanie,
- czas odpowiedzi serwera rośnie mimo poprawnie działającego frontendu,
- w logach lub narzędziach diagnostycznych widać dużo powtarzalnych zapytań do bazy danych.
Kiedy cache może powodować problemy
Cache nie powinien utrwalać danych, które muszą być aktualne dla konkretnego użytkownika lub konkretnej transakcji. W WooCommerce dotyczy to zwłaszcza koszyka, checkoutu, stanu zalogowania, metod płatności, danych dostawy oraz stanów magazynowych.
Problemy najczęściej pojawiają się wtedy, gdy kilka warstw cache działa jednocześnie bez spójnych reguł. Może to dotyczyć cache strony, CDN, wtyczek optymalizacyjnych i cache obiektowego. Sam Redis nie zapisuje gotowego HTML strony, ale źle skonfigurowana wtyczka lub integracja może nieprawidłowo obsługiwać dane dynamiczne.
Objawy nieprawidłowego cache w WooCommerce mogą obejmować:
- koszyk nie aktualizuje się po dodaniu lub usunięciu produktu,
- użytkownik widzi nieaktualną liczbę produktów w koszyku,
- checkout pokazuje stare dane dostawy lub płatności,
- stan magazynowy nie zmienia się po zakupie,
- cena, promocja lub dostępność produktu odświeża się z opóźnieniem,
- strona zachowuje się inaczej dla użytkownika zalogowanego i niezalogowanego,
- problem znika po wyczyszczeniu cache.
W przypadku WooCommerce warto traktować koszyk i checkout jako obszary dynamiczne. Szczegółowe zasady dotyczące cache dla WooCommerce na CDN opisuje artykuł WooCommerce na CDN – co cache’ować, czego nie.
Jak rozpoznać, że strona potrzebuje cache obiektowego
Cache obiektowy warto rozważyć, gdy największym problemem nie jest rozmiar obrazów ani statycznych plików, ale czas generowania odpowiedzi przez WordPressa. Typowym sygnałem jest wolny pierwszy bajt odpowiedzi, wolne działanie panelu administracyjnego lub spadek wydajności przy większej liczbie użytkowników.
Na potrzebę Redis może wskazywać także sytuacja, w której strona ma poprawnie ustawiony cache strony, ale nadal wolno działają elementy zalogowane, wyszukiwarki, filtry, koszyk lub checkout. W takich miejscach pełny cache HTML zwykle nie jest dobrym rozwiązaniem, ponieważ treść zależy od użytkownika albo bieżących danych sklepu.
Jak podejść do konfiguracji Redis w WordPressie
Redis należy wdrażać jako warstwę cache obiektowego, a nie jako zamiennik wszystkich pozostałych mechanizmów cache. Po włączeniu warto sprawdzić najważniejsze ścieżki użytkownika: listę produktów, kartę produktu, koszyk, checkout, logowanie i panel administracyjny.
Jeśli nie chcesz korzystać z wtyczki LiteSpeed Cache, która jest instalowana domyślnie po uruchomieniu aplikacji WordPress z poziomu dPanelu, możesz użyć wtyczki Redis Cache do cache obiektowego. Instrukcja konfiguracji znajduje się w artykule Jak skonfigurować wtyczkę Redis Cache dla CMS WordPress?.
Co jest normalne po włączeniu Redis
Po włączeniu Redis pierwsze żądania mogą jeszcze budować cache. Pełny efekt jest zwykle widoczny dopiero po kilku wejściach na te same widoki lub po typowym ruchu użytkowników.
Normalne jest też to, że Redis nie przyspieszy jednakowo każdej części strony. Największą różnicę widać tam, gdzie WordPress często odczytuje te same dane. Jeśli problem wynika z zewnętrznej bramki płatności, wolnej odpowiedzi API albo błędnych reguł cache strony, sam cache obiektowy nie rozwiąże całej sytuacji.
Podsumowanie
Redis i cache obiektowy są przydatne dla dynamicznych WordPressów i sklepów WooCommerce, ponieważ zmniejszają liczbę powtarzalnych operacji na bazie danych. Najlepiej działają jako osobna warstwa obok poprawnie skonfigurowanego cache strony, z zachowaniem ostrożności dla koszyka, checkoutu, stanów magazynowych i danych zależnych od użytkownika.