Trwała pamięć podręczna obiektów WordPress – jak ją skonfigurować?

Czy komunikat o trwałej pamięci podręcznej obiektów w stanie witryny WordPress trochę Cię stresuje? A może widzisz w raporcie narzędzi typu GTmetrix czy Pingdom hasła Redis, cache, gzip i nie bardzo wiesz, od czego zacząć? Ten tekst pokazuje krok po kroku, jak skonfigurować trwałą pamięć podręczną obiektów w WordPressie i co przy okazji poprawić w wydajności.

Co to jest trwała pamięć podręczna obiektów w WordPress?

WordPress przy każdym wejściu na stronę pobiera dane z bazy MySQL. Chodzi o treści wpisów, ustawienia motywu, menu, widgety, opcje wtyczek. Przy małym ruchu tego nie widać, ale gdy rośnie liczba odwiedzających, rośnie też liczba zapytań do bazy i czas odpowiedzi serwera. Wtedy zaczynają się spowolnienia i błędy „timed out”.

Trwała pamięć podręczna obiektów (Object Cache) zapisuje wyniki tych zapytań w szybkiej pamięci, najczęściej w Redis. Dzięki temu WordPress nie musi za każdym razem pytać bazy o to samo. Dane są odczytywane z pamięci, która działa wielokrotnie szybciej niż dysk czy klasyczna baza danych. W efekcie spada obciążenie MySQL i skraca się czas ładowania strony.

Wbudowany mechanizm cache obiektowego w WordPressie działa bez zewnętrznych usług, ale jest „ulotny”. Dane giną przy każdym restarcie PHP, przy przeładowaniu procesów, czasem nawet po logowaniu się do panelu. Trwała pamięć podręczna obiektów z użyciem Redis pozwala przechowywać te dane dłużej, także między kolejnymi uruchomieniami PHP.

W stanie witryny widzisz komunikat o braku trwałej pamięci podręcznej, bo WordPress wykrył, że serwer ma Redis, ale nie jest on połączony z Twoją stroną. To nie oznacza błędu konfiguracji motywu czy wtyczek, tylko niewykorzystaną możliwość przyspieszenia strony.

Cache strony a cache obiektowy – czym się różnią?

Wtyczki takie jak LiteSpeed Cache, WP Rocket czy inny akcelerator tworzą statyczne kopie całych podstron. Użytkownik – zamiast „składania” strony za każdym razem z PHP i bazy – dostaje gotowy plik HTML. To ogromnie przyspiesza ładowanie, zwłaszcza przy dużym ruchu. Cache obiektowy działa głębiej, na poziomie pojedynczych zapytań do bazy, a nie całych stron.

Cache strony pomaga głównie anonimowym użytkownikom. Cache obiektowy poprawia działanie całego WordPressa, także w panelu administratora, wewnątrz motywu Astra, przy działaniu WooCommerce czy innych rozbudowanych dodatków. Oba typy pamięci dobrze się uzupełniają i na nowoczesnym hostingu WordPress zwykle działają razem.

Jak sprawdzić, czy Twój hosting wspiera Redis?

Kiedy w stanie witryny widzisz zdanie w stylu „Twój host wydaje się wspierać następujące usługi zapisu w pamięci podręcznej obiektów: Redis”, oznacza to, że serwer ma włączony Redis albo przynajmniej jest przygotowany do jego obsługi. Nie każda firma hostingowa oferuje tę usługę na zwykłych planach, ale w pakietach „hosting WordPress” Redis pojawia się coraz częściej.

W panelach typu DirectAdmin czy cPanel zwykle znajdziesz osobną sekcję związaną z Redis. W cyber_Folks to zakładka „Ustawienia Redis” w sekcji „Pozostałe ustawienia”. Tam widać host, port i hasło do połączenia. Na innych serwerach (np. lh.pl) dane dostajesz po zgłoszeniu do supportu lub masz je opisane w dokumentacji pakietu.

Jak rozmawiać z supportem hostingu?

Gdy nie widzisz w panelu żadnej opcji Redis, warto wysłać krótkie pytanie do obsługi. Często wystarczy prosty mail, w którym jasno opiszesz, czego potrzebujesz. W odpowiedzi dostaniesz informację, czy Redis jest dostępny, na jakim porcie działa i czy wymaga hasła.

W wiadomości do hostingu możesz napisać między innymi: że korzystasz z WordPressa, że w stanie witryny widzisz sugestię włączenia trwałej pamięci podręcznej obiektów i że chcesz skonfigurować połączenie z Redis przez wtyczkę LiteSpeed Cache lub inną wtyczkę do cache obiektowego. To ułatwi konsultantowi przygotowanie kompletnej odpowiedzi.

Redis jest zwykle włączony domyślnie w planach „hosting WordPress”. Często wystarczy skopiować dane połączeniowe z panelu i wkleić je do ustawień wtyczki.

Co zrobić, jeśli Redis nie jest dostępny?

Zdarza się, że na tańszych pakietach hosting blokuje Redis, bo wymaga on osobnych zasobów serwera. Wtedy masz kilka opcji. Możesz pozostać tylko przy cache strony (np. LiteSpeed Cache bez obiektu). Możesz przesiąść się na pakiet hosting WordPress z Redis. Możesz też rozważyć innego dostawcę, jeśli zależy Ci na maksymalnej wydajności.

Nawet bez Redis warto zadbać o dobrą konfigurację PHP. Plik .user.ini pozwala zwiększyć memory_limit, max_execution_time czy upload_max_filesize. Wyższe limity zmniejszają ryzyko błędów podczas aktualizacji wtyczek, importu danych czy generowania miniatur zdjęć, co pośrednio też wpływa na płynność działania WordPressa.

Jak skonfigurować Redis w LiteSpeed Cache?

Na hostingu z serwerem LiteSpeed Enterprise masz do dyspozycji moduł LSCache. To on serwuje stronę z pamięci po stronie serwera. Wtyczka LiteSpeed Cache dla WordPress pełni rolę panelu sterowania tym mechanizmem oraz innych optymalizacji. Jedna z zakładek to właśnie konfiguracja cache obiektowego dla Redis.

Aby całość działała, trzeba wykonać kilka prostych kroków. Najpierw instalujesz wtyczkę z repozytorium, potem aktywujesz cache strony, a na końcu konfigurujesz zakładkę „Object” z danymi do Redis. Po zapisaniu ustawień i pozytywnym teście połączenia możesz przestać martwić się komunikatem ze stanu witryny.

Instalacja i podstawowa konfiguracja LiteSpeed Cache

Po zalogowaniu do panelu Wtyczki → Dodaj nową wpisujesz w wyszukiwarce „LiteSpeed Cache”. Następnie instalujesz i włączasz wtyczkę. Po aktywacji pojawi się nowe menu w panelu WordPressa, dzięki któremu ustawisz pamięć podręczną dla całej strony oraz inne opcje wydajnościowe.

W menu LiteSpeed Cache przechodzisz do zakładki „Pamięć podręczna” i na karcie głównej upewniasz się, że Enable Cache ma status „Włącz”. W tym momencie działa już cache strony po stronie serwera. Wielu hostingodawców – np. cyber_Folks – wstępnie ustawia rozsądne domyślne wartości, więc możesz od razu zobaczyć skrócenie czasu ładowania.

Ustawienia karty „Object” (pamięć podręczna obiektów)

Drugi krok to przejście do LiteSpeed Cache → Pamięć podręczna → karta „Object”. W sekcji „Pamięć podręczna obiektów” ustawiasz przełącznik na „Wł.” i w polu „Metoda” wybierasz Redis. Niżej pojawią się pola na dane połączeniowe. Ich wartości musisz skopiować z panelu hostingu.

Najczęściej wypełniasz następujące pola: Host, Port i Hasło. W niektórych instrukcjach pojawia się też pole „Nazwa użytkownika”, które dawniej było wymagane. Obecnie w wielu konfiguracjach – przykładowo po aktualizacji z 27.05.2024 w cyber_Folks – to pole pozostaje puste. Ważne, żeby host, port i hasło były wpisane dokładnie tak, jak podane w panelu.

Trwałe połączenie i zapisywanie danych tymczasowych

Na tej samej karcie w LiteSpeed Cache znajdziesz przełączniki Trwałe połączenie oraz Zapisuj dane tymczasowe. Włączenie ich pozwala ograniczyć liczbę nowych połączeń do Redis i lepiej wykorzystać możliwości cache obiektowego. Dane z bazy są przechowywane dłużej i szybciej pobierane przy kolejnych wejściach na stronę.

Po zapisaniu ustawień zajrzyj do sekcji „Stan” na dole strony. Kliknij przycisk testu połączenia. Jeśli wszystko działa, w polu „Test połączenia” zobaczysz zielony status „Zaliczono”. W razie innego komunikatu sprawdź, czy w wersji PHP Twojej domeny aktywne jest rozszerzenie Redis. W wielu panelach możesz je włączyć jednym kliknięciem w sekcji „Rozszerzenia PHP”.

Jak sprawdzić, czy strona korzysta z cache?

Sam komunikat „Zaliczono” przy teście połączenia to dobry znak, ale warto jeszcze upewnić się, że faktycznie korzystasz z cache. W przypadku LSCache możesz to zrobić na specjalnej stronie testowej lub analizując nagłówki odpowiedzi HTTP. To ważne, gdy optymalizujesz stronę pod kątem raportów GTmetrix, Pingdom czy PageSpeed Insights.

Przy serwerze LiteSpeed prostym narzędziem jest strona check.lscache.io. Wystarczy, że wpiszesz adres swojej strony, poczekasz na skan i odczytasz komunikaty. Gdy wszystko działa, zobaczysz dwie informacje: „LSCache is supported” oraz „LiteSpeed cache is a hit”. Brak drugiego oznacza, że cache jeszcze się nie wygenerował lub coś go blokuje.

Dlaczego LSCache nie zawsze jest „hit” od razu?

Cache strony generuje się przy pierwszym wejściu użytkownika na daną podstronę. Jeśli zaraz po konfiguracji uruchomisz test, narzędzie może jeszcze nie widzieć gotowego pliku HTML. Wystarczy wtedy otworzyć stronę główną jako niezalogowany użytkownik, przejść kilka kluczowych podstron i dopiero potem powtórzyć test. Po krótkim czasie komunikat „LiteSpeed cache is a hit” powinien się pojawić.

Niekiedy wtyczki bezpieczeństwa, nietypowe reguły .htaccess lub niewłaściwe ustawienia cache dla zalogowanych użytkowników blokują generowanie LSCache. Wtedy dobrze jest na chwilę wyłączyć inne wtyczki związane z cache, sprawdzić działanie tylko LiteSpeed Cache, a potem stopniowo z powrotem włączać pozostałe dodatki.

Jak testy wydajności pokazują zysk z Redis?

W testach wykonanych narzędziem Siege na identycznej stronie, serwer z LiteSpeed i Redis obsługiwał w ciągu 30 sekund około 32 000 użytkowników. Ten sam WordPress, ale bez tych rozwiązań, kończył test na niecałych 500 osobach. Różnica wynika właśnie z odciążenia bazy danych przez cache obiektowy i cache strony.

Tak duże liczby nie zawsze są Twoim celem, ale te dane dobrze obrazują, jak wiele może dać odpowiednia konfiguracja. Nawet jeśli Twoja strona ma kilkaset wejść dziennie, większa wydajność przekłada się na stabilniejszą pracę panelu, mniejszą liczbę błędów przy aktualizacjach i lepsze wyniki w narzędziach typu PageSpeed.

Jak połączyć Redis, cache strony i inne optymalizacje?

Redis i LiteSpeed Cache to mocny fundament, ale raporty takie jak „Performance grade C71, 116 requests, 3.2 MB, F0 Make fewer HTTP requests” pokazują jeszcze inne obszary do poprawy. Testy najczęściej zwracają uwagę na liczbę żądań, wielkość strony, brak nagłówków Expires czy brak kompresji gzip. Tymi elementami także można zająć się w jednym miejscu, właśnie w wtyczce cache.

Wynik w stylu „F0 Make fewer HTTP requests” sugeruje, że Twoja strona ładuje dużo plików CSS, JavaScript, obrazów, fontów i ikon. Część z nich pochodzi z motywu Astra, część z wtyczek, część z zewnętrznych serwisów (np. Google Fonts, skrypty analityczne). Im więcej takich zasobów, tym dłużej trwa pełne załadowanie strony.

Jak użyć LiteSpeed Cache do zmniejszenia liczby żądań?

Wtyczka LiteSpeed Cache posiada sekcje związane z optymalizacją CSS, JS oraz HTML. Włączenie łączenia plików, opóźniania ładowania skryptów czy lazy load dla obrazów pozwala ograniczyć liczbę HTTP requests bez ręcznej edycji kodu motywu Astra. To ważne, gdy nie chcesz ingerować w szablon, a chcesz lepszy wynik w testach.

W ramach ustawień optymalizacyjnych możesz wykorzystać między innymi następujące funkcje:

• łączenie i minimalizację plików CSS,
• łączenie i minimalizację plików JavaScript,
• odkładanie w czasie ładowania skryptów, które nie są potrzebne od razu,
• lazy load dla obrazków i iframe, żeby wczytywały się dopiero, gdy są widoczne.

Takie działania nie są podsumowaniem, ale naturalnym rozwinięciem konfiguracji Redis. Dopiero połączenie cache obiektowego, cache strony i optymalizacji zasobów frontendu daje wyraźny efekt w realnym czasie ładowania.

Gzip i nagłówki Expires – o co chodzi?

Kiedy w raporcie widzisz „F23 Compress components with gzip” i „F1 Add Expires headers”, narzędzie sygnalizuje brak kompresji oraz brak nagłówków mówiących, jak długo przeglądarka ma trzymać pliki w cache. Gzip (lub Brotli) zmniejsza rozmiar przesyłanych plików tekstowych, takich jak HTML, CSS, JS. Nagłówki Expires i Cache-Control mówią przeglądarce, że może przechowywać np. style i skrypty przez dłuższy czas.

Na serwerach LiteSpeed kompresja gzip jest zwykle włączona globalnie. Jeśli test jej nie widzi, hosting może wymagać ręcznej aktywacji w panelu, albo nagłówki giną przez nietypowe reguły .htaccess. Wiele opcji związanych z nagłówkami Expires LiteSpeed Cache potrafi ustawić automatycznie, dzięki czemu kolejne wejścia użytkownika na stronę będą szybsze, bo przeglądarka pobierze część plików z własnej pamięci podręcznej.

Jak zmniejszyć liczbę zapytań DNS?

Komunikat „Reduce DNS lookups” oznacza, że strona korzysta z wielu zewnętrznych domen. Mogą to być fonty z Google Fonts, mapy, skrypty analityczne, widgety social media czy wideo z innych serwisów. Każda nowa domena to dodatkowe pytanie DNS, co wydłuża czas początkowego ładowania.

Żeby ograniczyć liczbę zapytań DNS, możesz między innymi:

• zmniejszyć liczbę zewnętrznych fontów i rozważyć hostowanie ich lokalnie,
• usunąć nieużywane wtyczki ładujące skrypty z innych domen,
• ograniczyć liczbę narzędzi analitycznych i pikseli marketingowych,
• w miarę możliwości korzystać z jednego CDN, który obsłuży większość statycznych plików.

Takie zmiany często wynikają z przeglądu konfiguracji witryny, a nie tylko z pracy na poziomie serwera. Dlatego przy okazji wdrażania Redis i cache warto spojrzeć na listę wtyczek, skryptów i integracji, które z czasem mogły się nagromadzić.

Czy motyw domyślny ma wpływ na pamięć podręczną?

W raporcie stanu witryny WordPress widzisz też komunikat o „braku motywu domyślnego”. Twoja strona działa na motywie Astra i wszystko jest w porządku. Motyw domyślny typu Twenty Twenty-Three czy Twenty Twenty-Four to po prostu zapasowy szablon, który WordPress może uruchomić, gdyby obecny motyw przestał działać.

Dodanie jednego domyślnego motywu nie wpływa na działanie Redis, LSCache ani kompresji gzip. Może natomiast pomóc w diagnozie problemów, jeśli kiedyś po aktualizacji Astra zaczną pojawiać się błędy. Wtedy wystarczy tymczasowo przełączyć się na motyw domyślny i sprawdzić, czy problem dotyczy kodu motywu czy innej części konfiguracji.

Motyw domyślny jest rodzajem „bezpiecznika”. Nie przyspieszy strony, ale pomaga szybciej znaleźć źródło problemu po aktualizacjach.

W kontekście pamięci podręcznej ważne jest coś innego: żeby motyw dobrze współpracował z wybranym systemem cache. Astra jest znana z dobrej integracji z LiteSpeed Cache, więc przy poprawnie skonfigurowanym Redis i LSCache możesz liczyć na szybkie ładowanie zarówno strony głównej, jak i podstron wpisów czy sklepów.