Cache witryny & wewnętrzny cache serwera: jak działa pamięć podręczna WordPressa
Sprawdzenie cache witryny i wewnętrznego cache serwera na serwerze Nginx + Apache pokazało, że żądania stron WordPressa schodzą kolejno od przeglądarki przez CDN, cache stron, OPcache i Redis i zatrzymują się na warstwie, która ma kopię. Żądania stron, które trafiły prosto na serwer źródłowy, dostawały od nginx od razu plik HTML utworzony przez WP Rocket i nie schodziły do PHP ani bazy danych.
Ⅰ. Struktura cache w WordPressie
W informatyce cache (pamięć podręczna) to technika tymczasowego przechowywania danych, by mieć do nich szybki dostęp; w sieci działa na tej samej zasadzie i wyraźnie poprawia wydajność.
Dzięki temu, że cache przechowuje dane, przy każdej wizycie na stronie nie trzeba prosić serwera o wszystko od nowa: zapisane dane wczytują się szybko, a czas ładowania strony się skraca. Zmniejsza to obciążenie serwera i poprawia wygodę użytkowników.
Cache używany przy żądaniach WordPressa dzieli się na dwie gałęzie: cache witryny i wewnętrzny cache serwera. Standard cache HTTP, jak opisuje go MDN, nazywa cache zapisany tylko w przeglądarce jednego odwiedzającego private cache, a cache CDN i proxy, z których korzysta wielu odwiedzających, shared cache; w tym wpisie oba połączono pod nazwą cache witryny.
Cache stron, OPcache i cache obiektów to cache działające w procesie, w którym WordPress uruchamia się na serwerze. Standard HTTP nie ma dla nich osobnej kategorii, a oficjalna dokumentacja WordPressa opisuje je jako wtyczki cache (cache stron), cache obiektów i cache serwera (cache opcode, np. OPcache).
Wszystkie obszary, w których stosuje się cache, opisano we wpisie Cache: definicja i wszystkie obszary, w których stosuje się buforowanie oraz cztery gałęzie optymalizacji wydajności, w tym cache, we wpisie Optymalizacja wydajności stron: struktura i definicja poświęconym temu zagadnieniu.
W symulatorze poniżej wybierz cache w drzewie po lewej i kliknij przycisk, a zobaczysz, na której warstwie zatrzymuje się żądanie. Pierwsza warstwa, którą administratorzy WordPressa włączają wtyczką cache, to cache stron.
| Warstwa | Miejsce zapisu | Co zapisuje | Przykład dla Nginx + Apache |
|---|---|---|---|
| Cache przeglądarki | Urządzenie odwiedzającego | HTML · CSS · JS · obrazy · fonty | CSS · obrazy 7 dni |
| Cache CDN · proxy | Przed serwerem (edge · reverse proxy) | Kopie stron · plików statycznych | Bunny CDN |
| Cache strony | Dysk · pamięć serwera | HTML utworzony przez PHP | WP Rocket + nginx |
| OPcache | Pamięć serwera | Kod bajtowy PHP | PHP 8.3, JIT wyłączony |
| Cache obiektów | Pamięć serwera | Wyniki zapytań · obiekty | Redis |
Ⅱ. Cache witryny
Cache witryny to cache, w którym serwer w nagłówkach odpowiedzi podaje, jak przechowywać zasób, a przeglądarka odwiedzającego oraz CDN i proxy zapisują kopię zgodnie z tą instrukcją. Typowe nagłówki to [Cache-Control], [ETag] i [Expires]; gdy okres przechowywania minie, żądanie warunkowe ([304 Not Modified]) sprawdza, czy coś się zmieniło.
1️⃣ Cache przeglądarki
Cache przeglądarki to cache HTTP zapisany w przeglądarce odwiedzającego: przechowuje HTML, CSS, JavaScript, obrazy i fonty, a gdy ten sam zasób jest potrzebny ponownie, nie odwołuje się do serwera albo tylko sprawdza, czy się zmienił.
Okres przechowywania ustala serwer, a nie odwiedzający. Poniższy serwer Nginx + Apache wskazuje dla CSS i obrazów 7 dni, a strony HTML zwraca bez okresu, tak by przy każdej kolejnej wizycie były sprawdzane od nowa.
If-None-Match: "6ab12775-2ee8"cache-control: max-age=604800 expires: Sat, 17 Oct 2026 03:21:00 GMT etag: "6ab12775-2ee8"
etag: "6ac9298c-95575" last-modified: Fri, 09 Oct 2026 17:51:08 GMT
2️⃣ Cache CDN · proxy
Cache CDN i proxy znajduje się między odwiedzającymi a serwerem źródłowym i korzysta z niego wielu odwiedzających. Proxy przekazujące (forward proxy) stoi z przodu po stronie odwiedzającego, jak w sieci firmowej, a reverse proxy i CDN stoją przed serwerem i zamiast serwera źródłowego odpowiadają zapisaną kopią.
Typowym reverse proxy jest Varnish Cache, a sieci CDN, takie jak Bunny CDN i Akamai, mają tę samą budowę. Dzięki DNS zależnemu od regionu odwiedzający z regionu serwera źródłowego łączą się z nim bezpośrednio, a odwiedzającym z innych regionów odpowiada pobliski serwer brzegowy CDN (np. Bunny CDN), który przechowuje nawet HTML.
Budowę i zalety CDN opisano we wpisie Czym jest CDN? Powody, by z niego korzystać, i 5 zalet poświęconym temu zagadnieniu.
Ⅲ. Wewnętrzny cache serwera
Wewnętrzny cache serwera to cache działający w procesie, w którym WordPress buduje stronę, gdy żądanie dotrze już do serwera źródłowego. Serwer z Nginx + Apache obsługuje żądania w poniższej kolejności, a jeśli wcześniejszy etap znajdzie kopię, kolejne etapy są pomijane.
Konfigurację Nginx + Apache można wybrać jako opcję w Cloudways i ScalaHosting. W Cloudways dla każdej aplikacji wybierasz Hybrid stack (Nginx + Apache) albo Lightning stack (tylko Nginx), a w ScalaHosting możesz włączyć w SPanel ustawienie, które stawia Nginx przed Apache.
| Cache | Co zapisuje | Kiedy jest zapisywane |
|---|---|---|
| 1️⃣ Cache stron | Gotowa strona HTML | 🅑 ⑤ Przy odpowiedzi WP Rocket zapisuje do pliku |
| 2️⃣ OPcache | Skompilowany kod PHP (kod bajtowy) | 🅑 ② Gdy plik PHP uruchamia się pierwszy raz |
| 3️⃣ Cache obiektów | Fragmenty danych, np. wyniki zapytań i opcje | 🅑 ③ Gdy WordPress pierwszy raz pobiera dane |
1️⃣ Cache stron
Cache stron nazywa się też cache całych stron (full-page cache), a ponieważ przechowuje HTML, bywa nazywany cache HTML. Zapisuje całą stronę utworzoną przez PHP jako statyczny plik HTML, a przy żądaniu tej samej strony wysyła ten plik bez uruchamiania PHP. To przypadek 🅐 w kolejności obsługi powyżej.
Trafia do pamięci serwera (RAM) albo na dysk (HDD/SSD): pamięć jest szybka, ale droga i ma ograniczoną pojemność, a dysk ma dużo miejsca, ale jest stosunkowo wolny.
| Typ | Przykład | Sposób zapisu i odpowiedzi |
|---|---|---|
| Wtyczka cache | WP Rocket · WP Super Cache · W3 Total Cache · Cache Enabler | WordPress zapisuje stronę jako plik HTML, a serwer WWW wysyła ten plik. |
| Cache serwera WWW | Cache FastCGI Nginx · LiteSpeed Cache | Serwer WWW sam zapisuje odpowiedź PHP i wysyła ją przy kolejnym żądaniu. |
| Cache reverse proxy | Varnish | Serwer cache postawiony przed serwerem WWW zapisuje stronę i odpowiada. |
W konfiguracji Nginx + Apache nginx sam czyta i wysyła plik HTML utworzony przez WP Rocket, a nagłówek odpowiedzi dostaje [x-rocket-nginx-serving-file: HIT]. Jak włączyć i skonfigurować cache stron w WP Rocket, opisano we wpisie Konfiguracja WP Rocket poświęconym temu zagadnieniu.
2️⃣ OPcache
OPcache zapisuje w pamięci kod bajtowy wcześniej skompilowanego kodu PHP, więc przy ponownym uruchomieniu tego samego pliku parser PHP jest pomijany. Jest wbudowany domyślnie od PHP 5.5, a dawniej używane APC i XCache nie obsługują PHP 7 i dziś się ich nie używa. To etap ② ścieżki 🅑 w kolejności obsługi powyżej.
| Typ | Stan | Opis |
|---|---|---|
| Zend OPcache | Wbudowany od PHP 5.5 | Standardowy cache opcode używany obecnie; włącza się go przez [opcache.enable=1]. |
| OPcache JIT | Część OPcache od PHP 8 | Zamienia kod bajtowy jeszcze raz na kod maszynowy i go wykonuje; włącza i wyłącza się go przez [opcache.jit]. |
| APC | Rozwój zakończony | Cache opcode używany przed OPcache; funkcja cache danych przeszła do APCu. |
| XCache | Rozwój zakończony | Nie obsługuje PHP 7. |
| WinCache | Dla serwerów Windows (IIS) | Cache opcode, który oficjalna dokumentacja WordPressa wymienia obok OPcache. |
OPcache włącza się ustawieniem PHP [opcache.enable=1], a JIT, który doszedł w PHP 8, można osobno wyłączyć przez [opcache.jit=disable]. Instalację i konfigurację opisano we wpisie Zend OPcache: pojęcie, instalacja i konfiguracja poświęconym temu zagadnieniu.
3️⃣ Cache obiektów
Cache obiektów zapisuje wyniki zapytań do bazy danych lub obliczone obiekty w magazynie w pamięci, takim jak Redis czy Memcached. Domyślnie WordPress pamięta obiekty tylko w obrębie jednego żądania; żeby wyniki zostały także po jego zakończeniu, trzeba podłączyć magazyn taki jak Redis. To etap ③ ścieżki 🅑 w kolejności obsługi powyżej.
| Typ | Rodzaj | Zostaje po żądaniu? | Opis |
|---|---|---|---|
| WP_Object_Cache | Domyślny w WordPressie | Nie | Wbudowany cache, który pamięta tylko w obrębie jednego żądania. |
| Redis | Cache obiektów | Tak | Osobny magazyn w pamięci, podłączany przez drop-in wtyczki Redis Object Cache. |
| Memcached | Cache obiektów | Tak | Osobny magazyn w pamięci. |
| APCu | Cache obiektów | Tak (w obrębie tego samego serwera) | Zapisuje we współdzielonej pamięci używanej przez PHP. |
| Plik | Cache obiektów | Tak | Zapisuje jako pliki na dysku. |
| Pula buforów InnoDB | Własny cache bazy danych · nie cache obiektów | Tak | MySQL i MariaDB trzymają dane tabel i indeksy w pamięci. |
| Cache zapytań | Własny cache bazy danych · nie cache obiektów | — | Usunięty w MySQL 8.0; w MariaDB nadal jest, ale domyślnie wyłączony. |
WordPress łączy się z Redis przez plik drop-in ([object-cache.php]), który dodaje wtyczka Redis Object Cache. Instalację opisano we wpisie Instalacja i konfiguracja Redis Cache w WordPressie poświęconym temu zagadnieniu.
🔢 FAQ & polecane treści
ℹ️ Informacja o linkach partnerskich
Treści tej witryny zawierają linki partnerskie. Jeśli odwiedzający kupi produkt lub usługę przez taki link, witryna otrzymuje od sprzedawcy prowizję. Kwota płacona przy tym przez kupującego (podczas promocji spada↓) nie wzrasta. Podane ceny, rabaty i dostępność odnoszą się do chwili pisania i mogą różnić się od stanu faktycznego, dlatego przed zakupem sprawdź je u sprzedawcy. Produkty wybieramy i oceniamy według własnych kryteriów, a prowizja nie wpływa ani na kolejność prezentacji, ani na treść ocen.