Pamięć podręczna (Cache) w WordPressie – rodzaje, mechanizmy i wpływ na Time to First Byte (TTFB)

WordPress bez cache działa jak kuchnia, która dla każdego gościa od nowa mieli ziarna, rozpala piec, kroi warzywa i dopiero wtedy wydaje talerz. Przy małym ruchu da się tak żyć. Przy większym — serwer zaczyna dławić się własną pracą: PHP wykonuje kolejne skrypty, baza danych odpowiada na te same zapytania, motyw składa HTML, a użytkownik czeka na pierwszy bajt odpowiedzi.

Cache WordPress rozwiązuje ten problem nie przez „magiczne przyspieszenie strony”, tylko przez pomijanie pracy, której nie trzeba powtarzać. Jeżeli treść podstrony nie zmieniła się od ostatniej wizyty, serwer nie musi budować jej od zera. Może podać gotowy wynik. To właśnie dlatego dobrze ustawiona pamięć podręczna potrafi obniżyć TTFB WordPress z wartości rzędu 1–2 sekund do kilkuset milisekund. Nie zawsze. Nie na każdym hostingu. Ale różnica bywa brutalnie widoczna, zwłaszcza na stronach z rozbudowanym motywem, WooCommerce, page builderem albo dużą liczbą wtyczek.

Najważniejsze: cache nie jest jedną funkcją. To kilka warstw, które działają w różnych miejscach. Page cache przechowuje gotowy HTML. Object cache odciąża bazę danych. Browser cache zostawia statyczne pliki w przeglądarce użytkownika. Dopiero zrozumienie różnicy między nimi pozwala dobrać sensowne rozwiązanie, zamiast instalować kolejną wtyczkę „do szybkości” i liczyć, że problem sam zniknie.

Czym jest cache i dlaczego drastycznie skraca czas odpowiedzi serwera (TTFB)

Cache to tymczasowo zapisany wynik wcześniejszej pracy systemu. W WordPressie tą pracą może być wygenerowana strona HTML, wynik zapytania do bazy danych, lista produktów, menu, plik CSS, obraz, font albo odpowiedź API. Zamiast wykonywać te same operacje przy każdym wejściu użytkownika, WordPress lub serwer podaje zapisaną kopię.

Najprościej widać to na przykładzie zwykłego wpisu blogowego. Bez cache typowe żądanie wygląda tak:

• użytkownik otwiera adres URL,
• serwer uruchamia WordPressa,
• PHP ładuje pliki rdzenia, motywu i wtyczek,
• WordPress odpytuje bazę danych o treść wpisu, ustawienia, menu, widgety, komentarze i metadane,
• motyw składa z tego HTML,
• serwer odsyła gotową odpowiedź do przeglądarki.

Przy jednym użytkowniku brzmi niewinnie. Przy 200 osobach naraz robi się kosztownie. Każde wejście może oznaczać dziesiątki lub setki zapytań do bazy danych oraz pełne uruchomienie PHP. Pamięć podręczna WordPress skraca tę ścieżkę. Dobrze ustawiony page cache pozwala serwerowi zwrócić gotowy HTML bez ponownego odpytywania bazy i bez pełnego przetwarzania WordPressa.

Tu pojawia się TTFB, czyli Time to First Byte. To czas od wysłania żądania przez przeglądarkę do otrzymania pierwszego bajtu odpowiedzi z serwera. W praktyce TTFB pokazuje, jak szybko serwer zaczyna odpowiadać. Nie mierzy całego ładowania strony, nie mówi wszystkiego o JavaScripcie, obrazach i renderowaniu, ale jest bardzo dobrym sygnałem, czy backend nie męczy się przy generowaniu dokumentu HTML.

Dla strony WordPress wysoki TTFB najczęściej oznacza jeden z kilku problemów:

• zbyt wolny hosting lub przeciążony serwer,
• brak cache strony HTML,
• zbyt ciężki motyw lub builder,
• wolne zapytania do bazy danych,
• nadmiar wtyczek uruchamianych przy każdym żądaniu,
• zewnętrzne zapytania API blokujące wygenerowanie strony,
• źle ustawiony WooCommerce, koszyk, sesje lub personalizacja.

Cache nie naprawia wszystkiego. To ważne. Jeżeli serwer jest skrajnie słaby, baza danych zapchana, a motyw ładuje pół panelu administracyjnego na froncie, sama wtyczka cache tylko ukryje część problemu. Ale w hierarchii działań przy WordPressie cache jest zwykle jednym z pierwszych ruchów, bo daje szybki efekt przy relatywnie niskim ryzyku.

Największy wpływ na TTFB WordPress ma zazwyczaj cache pełnej strony, czyli zapisanie gotowego HTML. Przy anonimowych użytkownikach, którzy nie są zalogowani i nie mają aktywnego koszyka, serwer może oddać gotowy dokument niemal od ręki. Przy użytkownikach zalogowanych, klientach WooCommerce, panelach kursantów czy stronach z dynamiczną personalizacją sytuacja jest trudniejsza. Wtedy pełny cache trzeba omijać albo dzielić stronę na fragmenty, żeby nie pokazać jednej osobie danych drugiej.

Istotne jest też miejsce, w którym cache zostaje obsłużony. Cache aplikacyjny, realizowany wyłącznie przez wtyczkę PHP, bywa wolniejszy od cache serwerowego, bo serwer nadal musi uruchomić interpreter PHP, aby WordPress lub wtyczka podały zapisany plik. Niektóre wtyczki omijają ten problem częściowo, zapisując reguły do .htaccess albo korzystając z mechanizmów typu drop-in/advanced-cache, które przechwytują żądanie wcześniej. Nadal jednak rozwiązania serwerowe, takie jak LiteSpeed Cache, Nginx FastCGI Cache czy Varnish, mają przewagę: mogą zwrócić gotowy HTML z pamięci RAM lub dysku zanim WordPress w ogóle zacznie pracować. Właśnie dlatego dobrze wdrożony cache serwerowy potrafi skrócić TTFB najmocniej.

To podstawowa decyzja graniczna: im bardziej statyczna strona, tym większy zysk z cache strony; im bardziej dynamiczna i spersonalizowana, tym ostrożniej trzeba go stosować.

Blog, serwis firmowy, landing page, baza wiedzy czy strona usługowa mogą korzystać z agresywnego page cache. Sklep internetowy też może, ale z wyjątkami dla koszyka, checkoutu, konta klienta i czasem stron z cenami zależnymi od użytkownika. Portal z płatnymi treściami, panelem użytkownika albo dynamicznymi wynikami musi mieć cache zaprojektowany uważniej.

Dobry cache nie polega więc na tym, żeby zapisać wszystko. Polega na tym, żeby zapisać to, co bezpieczne, i odświeżać to wtedy, gdy treść faktycznie się zmienia.

Strona, obiekt i przeglądarka: rodzaje pamięci podręcznej, które musisz znać

W WordPressie najczęściej spotkasz trzy warstwy cache: page cache, object cache i browser cache. Każda odpowiada za inny etap pracy strony. Mieszanie ich w jeden worek prowadzi do złych decyzji, bo problem z bazą danych rozwiązuje się inaczej niż problem z powtarzalnym pobieraniem obrazów.

Page cache, czyli cache strony, przechowuje gotowy HTML. To zwykle najważniejsza warstwa dla TTFB. Jeżeli użytkownik wchodzi na wpis blogowy, stronę kategorii albo landing page, serwer może podać zapisany dokument bez pełnego uruchamiania WordPressa. W praktyce oznacza to mniej pracy dla PHP, mniej zapytań do bazy i większą odporność na skoki ruchu.

Największe plusy page cache:

• najmocniej obniża TTFB dla stron publicznych,
• ogranicza zużycie CPU i RAM,
• pozwala obsłużyć większy ruch na tym samym hostingu,
• dobrze działa na blogach, stronach firmowych i landing page’ach,
• może współpracować z CDN, który podaje HTML z serwerów brzegowych.

Największe minusy:

• wymaga czyszczenia po zmianie treści,
• nie nadaje się bez wyjątków dla koszyka, checkoutu i kont użytkowników,
• może pokazywać nieaktualną wersję strony, jeżeli reguły odświeżania są źle ustawione,
• potrafi kolidować z personalizacją, testami A/B, geolokalizacją i dynamicznymi cenami.

W praktyce page cache powinien być pierwszym wyborem dla większości stron informacyjnych. Jeżeli serwis ma głównie publiczne treści, od niego zaczyna się optymalizację. Dopiero potem ma sens dłubanie w minifikacji CSS, lazy loadingu czy preloadzie fontów.

Object cache działa głębiej. Nie przechowuje całej strony HTML, tylko wyniki operacji wykonywanych przez WordPressa: zapytania, obiekty, dane opcji, transients, fragmenty obliczeń. W domyślnym WordPressie istnieje nieutrwalony cache obiektów działający tylko w ramach jednego żądania. Po zakończeniu ładowania strony znika. Persistent object cache, czyli trwały cache obiektów, zapisuje te dane między żądaniami, zwykle w Redisie lub Memcached.

Tu różnica jest ogromna na większych serwisach. Jeżeli WordPress przy każdym wejściu pobiera z bazy podobne dane, Redis może przejąć część tej pracy. Baza danych oddycha lżej, panel administracyjny działa szybciej, a strony dynamiczne mniej cierpią.

Object cache ma największy sens, gdy:

• strona ma dużo wpisów, produktów, taksonomii lub metadanych,
• działa WooCommerce,
• użytkownicy są zalogowani,
• serwis ma membership, LMS, forum lub katalog,
• baza danych jest częstym wąskim gardłem,
• hosting wspiera Redis lub Memcached.

Nie jest to jednak warstwa, którą zawsze warto wdrażać „bo brzmi profesjonalnie”. Na małej stronie wizytówkowej z kilkunastoma podstronami trwały object cache może dać niewielki efekt. Zdarza się też, że źle skonfigurowany Redis tworzy nowe problemy: przestarzałe dane, konflikty po migracji, błędne stany koszyka albo trudne do uchwycenia błędy w panelu. Jeżeli hosting nie oferuje stabilnego Redisa, lepiej najpierw dopracować page cache i hosting niż instalować przypadkowe rozwiązanie z poradnika.

Browser cache działa po stronie użytkownika. Przeglądarka zapisuje pliki statyczne: obrazy, CSS, JavaScript, fonty, ikony. Przy kolejnej wizycie nie musi pobierać ich ponownie albo może sprawdzić tylko, czy wersja pliku się zmieniła. To nie zawsze mocno obniży TTFB dokumentu HTML, bo pierwszy bajt strony nadal pochodzi z serwera. Za to znacząco skraca kolejne odsłony i ogranicza transfer.

Sterowanie tym procesem odbywa się za pomocą nagłówków HTTP, takich jak Cache-Control i Expires, wysyłanych przez serwer. Cache-Control: max-age informuje przeglądarkę, przez ile sekund dany zasób może być uznawany za świeży. Przykładowo max-age=31536000 oznacza rok. Nagłówek Expires wskazuje konkretną datę wygaśnięcia zasobu. W nowoczesnych konfiguracjach większe znaczenie ma Cache-Control, ale Expires nadal bywa używany dla zgodności i prostszych reguł serwerowych.

Browser cache jest szczególnie ważny dla:

• logo, ikon i grafik interfejsu,
• plików CSS i JS motywu,
• fontów lokalnych,
• obrazów używanych na wielu podstronach,
• zasobów, które rzadko się zmieniają.

Tu trzeba pilnować dwóch rzeczy: czasu życia plików i wersjonowania. Długi cache dla pliku CSS jest dobry, dopóki po zmianie wyglądu użytkownik nie widzi starej wersji strony. Dlatego pliki statyczne powinny mieć mechanizm zmiany wersji, na przykład przez parametr lub inną nazwę pliku po aktualizacji. Wtedy można ustawić dłuższe nagłówki cache bez ryzyka, że poprawka w layoucie utknie u użytkowników na kilka dni.

W tle działa jeszcze kilka warstw, które często pojawiają się przy WordPressie:

• CDN cache — przechowuje pliki, a czasem także HTML, na serwerach bliżej użytkownika.
• OPcache — przyspiesza wykonywanie PHP, przechowując skompilowany kod.
• Database cache — zapisuje wyniki zapytań do bazy; obecnie trzeba stosować go ostrożnie, bo nie zawsze daje korzyść i bywa problematyczny.
• Fragment cache — zapisuje tylko część strony, na przykład menu, blok produktów albo fragment generowany przez wtyczkę.

Najrozsądniejsza kolejność decyzji wygląda tak:

1. Najpierw sprawdź, czy działa page cache dla użytkowników niezalogowanych.
2. Potem ustaw poprawny browser cache dla zasobów statycznych.
3. Następnie oceń, czy potrzebujesz object cache — zwłaszcza przy WooCommerce, dużej bazie lub zalogowanych użytkownikach.
4. Dopiero później rozważ CDN, cache HTML na brzegu sieci, fragment cache i zaawansowane reguły wyjątków.

To podejście oszczędza czas. Najczęstszy błąd to zaczynanie od kosmetyki: minifikacji, łączenia plików, opóźniania skryptów i przypadkowego wyłączania funkcji motywu, podczas gdy serwer nadal generuje każdą stronę od zera.

Wtyczki cache dla WordPressa

Rynek wtyczek cache jest zatłoczony, ale w praktyce wybór zwykle zawęża się do kilku narzędzi. Nie ma jednej najlepszej wtyczki cache WordPress dla każdej strony. Liczy się hosting, typ strony, budżet, WooCommerce, poziom techniczny administratora i to, czy cache ma być prosty, czy bardzo konfigurowalny.

Ważna rzecz przed instalacją: wiele nowoczesnych hostingów współdzielonych ma domyślnie włączony własny page cache, często oparty o Nginx, Varnish, LiteSpeed albo autorskie rozwiązanie dostawcy. Taki cache bywa niewidoczny z poziomu WordPressa, ale realnie wpływa na to, co widzi użytkownik. Instalowanie dodatkowej wtyczki bez wyłączenia cache serwerowego albo bez integracji z nim prowadzi do podwójnego cache’owania. Efekt? Edytujesz wpis, czyścisz cache we wtyczce, a stara wersja nadal siedzi w warstwie hostingu. To jeden z najbardziej irytujących problemów przy optymalizacji WordPressa, bo administrator zaczyna szukać błędu w motywie, CDN albo przeglądarce, a winna jest druga, ukryta warstwa cache.

WP Rocket

WP Rocket to płatna wtyczka premium, wybierana często tam, gdzie liczy się szybkie wdrożenie bez ręcznego ustawiania kilkudziesięciu opcji. Ceny na oficjalnej stronie zaczynają się od 59 USD rocznie za 1 stronę, 119 USD rocznie za 3 strony i 299 USD rocznie za pakiet Multi dla 50 stron. Producent podaje też 14-dniową politykę zwrotu. To nie jest najtańszy wybór, ale jego sens polega na oszczędności czasu: page cache, preload, opóźnianie JavaScriptu, lazy load i część dobrych praktyk są spięte w jednym panelu.

WP Rocket warto rozważyć, gdy:

• strona zarabia i czas konfiguracji kosztuje więcej niż licencja,
• administratorem nie jest developer,
• potrzebujesz prostego panelu i wsparcia,
• masz typową stronę firmową, blog, landing page albo sklep z przewidywalnym ruchem.

Nie jest to najlepszy wybór, gdy budżet jest zerowy albo hosting już ma mocny cache serwerowy, którego nie warto dublować. Trzeba też uważać z funkcjami optymalizacji JavaScriptu. Opóźnianie skryptów potrafi poprawić wyniki testów, ale może zepsuć menu mobilne, formularz, popup, analitykę lub koszyk. Najpierw cache HTML, potem eksperymenty z JS.

LiteSpeed Cache

LiteSpeed Cache ma inną logikę. Sama wtyczka jest darmowa, ale pełnię możliwości pokazuje dopiero na serwerze LiteSpeed lub OpenLiteSpeed, bo korzysta z cache na poziomie serwera. To bardzo mocne rozwiązanie, gdy hosting jest z nim zgodny. LiteSpeed Cache obsługuje page cache, cache przeglądarki, optymalizację obrazów, integrację z QUIC.cloud CDN, object cache oraz funkcje optymalizacji CSS/JS.

Największa zaleta: wydajność. Cache serwerowy zwykle działa szybciej niż cache obsługiwany dopiero przez PHP. Dzieje się tak, ponieważ serwer zwraca gotowy plik przed uruchomieniem interpretera PHP, co maksymalnie skraca TTFB. Największe ryzyko: zbyt wiele opcji. Panel LiteSpeed Cache potrafi kusić do zaznaczania wszystkiego po kolei. To prosta droga do błędów w CSS, znikających elementów interfejsu i problemów z koszykiem.

LiteSpeed Cache wybierałbym przede wszystkim wtedy, gdy hosting faktycznie działa na LiteSpeedzie i nie blokuje funkcji cache. Na hostingu Apache lub Nginx nadal można używać części opcji optymalizacyjnych, ale główny argument tej wtyczki traci wtedy dużą część mocy.

W3 Total Cache

W3 Total Cache to narzędzie bardziej techniczne. Obsługuje page cache, object cache, browser cache, database cache, fragment cache, integracje CDN i wiele metod przechowywania danych, w tym Redis oraz Memcached. Wersja Pro kosztuje obecnie 99 USD rocznie za 1 stronę, 350 USD rocznie za 5 stron i 500 USD rocznie za 10 stron.

To dobra opcja dla osób, które wiedzą, co konfigurują. W3 Total Cache daje dużą kontrolę, ale nie wybacza przypadkowego klikania. Na prostej stronie może być przerostem formy nad treścią. Na większym WordPressie, szczególnie z Redisem, CDN i potrzebą szczegółowych reguł, ma sens.

W3 Total Cache warto brać pod uwagę, gdy:

• masz techniczną obsługę strony,
• chcesz osobno kontrolować różne warstwy cache,
• potrzebujesz integracji z Redisem, Memcached lub CDN,
• zależy Ci na diagnostyce i granularnych ustawieniach.

Odradzałbym go jako pierwszą wtyczkę dla osoby, która chce po prostu „przyspieszyć stronę”. Tu łatwo uzyskać odwrotny efekt: podwójny cache, błędne nagłówki, niepotrzebny database cache albo problemy z odświeżaniem treści.

WP Fastest Cache

WP Fastest Cache jest prostszy i bardziej przystępny. Tworzy statyczne pliki cache, obsługuje cache przeglądarki, GZIP, minifikację, optymalizację obrazów i WebP w wersji premium. Model premium na stronie producenta zaczyna się od 49 USD jednorazowo za pakiet Bronze dla 1 licencji oraz 125 USD jednorazowo za Silver dla 3 licencji. To ciekawa propozycja dla mniejszych stron, gdzie liczy się prostota i brak abonamentu.

Największy plus: niski próg wejścia. Największy minus: mniej zaawansowane scenariusze niż w W3 Total Cache czy konfiguracji serwerowej LiteSpeed. Dla strony firmowej, bloga albo niewielkiego serwisu usługowego często wystarczy. Dla dużego WooCommerce albo portalu z logowaniem lepiej dokładniej sprawdzić, czy reguły wyjątków i integracje są wystarczające.

Są też inne rozwiązania: WP Super Cache, Cache Enabler, Breeze, cache w hostingu zarządzanym, Cloudflare APO, Varnish, Nginx FastCGI Cache. Nie trzeba jednak zaczynać od długiej listy. Decyzję można uprościć:

• Masz hosting LiteSpeed? Najpierw sprawdź LiteSpeed Cache.
• Chcesz prostoty i masz budżet? Rozważ WP Rocket.
• Chcesz darmowego lub taniego rozwiązania dla małej strony? Sprawdź WP Fastest Cache albo WP Super Cache.
• Masz większy serwis i techniczną obsługę? Rozważ W3 Total Cache z Redisem lub Memcached.
• Masz hosting zarządzany z własnym cache? Najpierw użyj cache hostingu, a dopiero potem dokładaj wtyczkę.

Najgorszy wariant to kilka wtyczek cache naraz. Jedna od page cache, druga od minifikacji, trzecia od CDN, czwarta od Redisa, a do tego cache hostingu i Cloudflare z przypadkowymi regułami. Taki zestaw potrafi działać, ale tylko wtedy, gdy ktoś świadomie rozdziela odpowiedzialność. Bez tego pojawiają się typowe awarie:

• stary CSS po aktualizacji,
• niedziałający koszyk,
• błędne przekierowania,
• różne wersje strony dla użytkowników,
• brak pewności, gdzie wyczyścić cache,
• konflikt z wbudowanym cache hostingu, na przykład autorskim mechanizmem dostawcy serwera, Varnishem, Nginx FastCGI Cache albo cache w panelu hostingu.

Praktyczna zasada jest prosta: jedna główna warstwa page cache, jedna warstwa object cache tylko wtedy, gdy jest potrzebna, browser cache dla statycznych plików i świadome wyjątki dla treści dynamicznych.

Na start warto sprawdzić trzy rzeczy:

• czy HTML strony dla użytkownika niezalogowanego jest podawany z cache,
• czy koszyk, checkout, konto klienta i panel logowania są wyłączone z page cache,
• czy po publikacji lub edycji wpisu cache czyści się automatycznie dla właściwych adresów.

Dopiero gdy to działa, ma sens dopieszczanie reszty. Cache nie jest dekoracją do wyników PageSpeed Insights. To mechanizm kontroli pracy serwera. Źle ustawiony potrafi oszukać testy, ale zepsuć użytkownikom stronę. Dobrze ustawiony sprawia, że WordPress robi mniej, odpowiada szybciej i stabilniej znosi ruch.

FAQ

Czy cache w WordPressie zawsze poprawia TTFB?
Nie zawsze, ale bardzo często poprawia TTFB dla publicznych podstron. Największy efekt daje pełny cache HTML. Jeżeli problemem jest wolny DNS, odległość serwera, przekierowania, zewnętrzne API albo przeciążony hosting, sama wtyczka cache nie usunie całej przyczyny.

Jaki TTFB jest dobry dla WordPressa?
Dobrym celem jest TTFB poniżej 800 ms dla większości użytkowników. Wyniki powyżej 1,8 s są sygnałem alarmowym. W praktyce dla prostych stron z działającym page cache często da się zejść niżej, ale nie warto obiecywać jednej liczby bez testów z różnych lokalizacji i na realnym ruchu.

Czy WooCommerce może korzystać z cache?
Tak, ale z wyjątkami. Strony produktowe, kategorie i treści blogowe mogą być cache’owane. Koszyk, checkout, moje konto i fragmenty zależne od użytkownika powinny być wyłączone z pełnego cache albo obsługiwane specjalnymi mechanizmami. W przeciwnym razie można pokazać klientowi cudzy koszyk lub nieaktualną cenę.

Czy object cache jest potrzebny na każdej stronie?
Nie. Przy małej stronie firmowej większy efekt zwykle da page cache i dobry hosting. Object cache ma sens przy większych bazach, WooCommerce, użytkownikach zalogowanych, forach, kursach online i stronach, które wykonują dużo powtarzalnych zapytań do bazy danych.

Czym różni się cache serwerowy od cache we wtyczce WordPressa?
Cache serwerowy może zwrócić gotową odpowiedź zanim uruchomi się PHP i WordPress. Wtyczka aplikacyjna działa bliżej samego WordPressa, więc w wielu konfiguracjach część środowiska nadal musi zostać uruchomiona. Dlatego LiteSpeed Cache, Varnish albo Nginx FastCGI Cache potrafią mocniej skrócić TTFB niż proste zapisywanie plików statycznych przez wtyczkę.

Czy można używać dwóch wtyczek cache jednocześnie?
Zwykle nie warto. Dwie wtyczki próbujące robić page cache albo minifikację mogą sobie przeszkadzać. Bezpieczniej wybrać jedno główne narzędzie i jasno ustalić, co robi hosting, co robi wtyczka, a co robi CDN.

Dlaczego po edycji wpisu nadal widzę starą wersję strony?
Najczęściej działa więcej niż jedna warstwa cache. Możesz wyczyścić cache wtyczki, ale stara wersja nadal zostanie w cache hostingu, CDN, Varnishu, Nginx FastCGI Cache albo w przeglądarce. Dlatego przy diagnozie trzeba sprawdzać warstwy po kolei, a nie klikać „Wyczyść cache” w przypadkowych miejscach.

Czy cache może zaszkodzić SEO?
Może, jeżeli podaje nieaktualne treści, blokuje indeksację, pokazuje błędne wersje językowe, psuje linki kanoniczne albo ukrywa problemy z renderowaniem. Sam cache jest korzystny dla wydajności, ale tylko wtedy, gdy nie zmienia treści strony w sposób niekontrolowany.

Od czego zacząć optymalizację cache w WordPressie?
Najpierw sprawdź, czy strona główna, wpisy i podstrony publiczne są podawane z page cache. Potem ustaw browser cache dla plików statycznych. Object cache zostaw na moment, gdy widzisz realne obciążenie bazy danych albo masz WooCommerce, membership, LMS lub duży serwis treściowy.