Cache-control w WordPress – jak poprawnie skonfigurować?

Cache-Control w WordPressie powinien rozdzielać zasoby statyczne od treści dynamicznych. Obrazy, arkusze CSS i pliki JavaScript można przechowywać długo, natomiast strony zalogowanych użytkowników, koszyk i checkout WooCommerce muszą omijać współdzielony cache. Błąd w tej konfiguracji może spowodować wyświetlenie jednej osobie danych przygotowanych dla innej.

Czym jest Cache-Control w WordPressie?

Cache-Control to nagłówek HTTP, który informuje przeglądarkę oraz serwery pośredniczące, takie jak CDN, czy i jak długo mogą przechowywać odpowiedź. Dzięki temu ponowne pobieranie niezmiennych plików nie musi za każdym razem obciążać serwera.

W WordPressie trzeba jednak rozdzielić dwa rodzaje danych. Obraz logo, arkusz stylów czy czcionka są zwykle wspólne dla wszystkich odwiedzających. HTML koszyka, panel klienta lub strona użytkownika zalogowanego może zawierać dane zależne od sesji. Tego drugiego rodzaju treści nie należy udostępniać ze współdzielonego cache.

Najważniejsze dyrektywy Cache-Control

Przed konfiguracją warto znać znaczenie podstawowych dyrektyw. Ta sama strona może korzystać z różnych ustawień zależnie od rodzaju odpowiedzi:

Dyrektywa	Zastosowanie w WordPressie	Bezpieczeństwo
public	Obrazy, CSS, JavaScript, fonty i inne zasoby wspólne dla odwiedzających	Może być przechowywana we współdzielonym cache, także na CDN
private	Treść zależna od konkretnego użytkownika, przechowywana najwyżej w jego przeglądarce	Nie powinna trafić do wspólnego cache
no-cache	Zasób może zostać zapisany, ale przed użyciem wymaga ponownej walidacji	Nie oznacza całkowitego zakazu zapisu
no-store	Odpowiedzi zawierające dane sesji, koszyk, dane konta lub informacje poufne	Zabrania zapisywania odpowiedzi w cache
must-revalidate	Dane, które po wygaśnięciu nie mogą być użyte bez sprawdzenia na serwerze	Ogranicza użycie nieaktualnej kopii
max-age	Czas, przez który zasób jest uznawany za aktualny, podany w sekundach	Bezpieczny dla statyków, ale ryzykowny dla zmiennego HTML

Typowa reguła dla zasobu statycznego może wyglądać jak public, max-age=2592000, czyli przechowywanie przez 30 dni. Dla odpowiedzi ustawiającej sesję bezpieczniejszym wyborem będzie no-store. Dyrektywa no-cache jest bardziej restrykcyjna niż zwykłe użycie zapisanej kopii, ale nie zastępuje no-store, gdy chcesz całkowicie zabronić zapisu.

Jak skonfigurować Cache-Control w WordPressie?

Najpierw ustal, gdzie faktycznie działa cache. Przeglądarka może przechowywać pliki lokalnie, serwer może generować i podawać gotowy HTML, a CDN może przechowywać odpowiedzi na swoich węzłach. Ustawienia w jednym miejscu nie zawsze kontrolują pozostałe warstwy.

Sprawdź, czy hosting, CDN lub serwer używa własnego cache, na przykład Varnish albo mechanizmu dostępnego w panelu hostingu.
Ustaw długie czasy dla zasobów statycznych, takich jak obrazy, CSS, JavaScript, SVG i fonty. Dobrze sprawdza się zakres od kilku dni do 30 dni, jeśli pliki mają wersjonowane nazwy.
Wyłącz współdzielony cache dla stron zalogowanych, panelu administracyjnego i odpowiedzi zawierających ciasteczka sesyjne.
Skonfiguruj reguły w panelu CDN lub hostingu, jeśli dostawca udostępnia taką możliwość. Jest to zwykle bezpieczniejsze niż ręczne modyfikowanie plików serwera.
Wyczyść istniejący cache i sprawdź nagłówki odpowiedzi w przeglądarce, zanim uznasz konfigurację za zakończoną.

W przypadku Apache reguły można ustawić w pliku .htaccess. Przykład dla zasobów statycznych wymaga modułu mod_headers:

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|jpg|jpeg|png|gif|svg|webp|woff|woff2)$">
    Header set Cache-Control "public, max-age=2592000"
  </FilesMatch>
</IfModule>

To tylko przykład dla plików, które są wspólne dla odwiedzających. Nie dodawaj do tej reguły PHP ani dokumentów HTML bez sprawdzenia, czy nie zawierają danych sesyjnych. Wtyczki takie jak WP Rocket lub W3 Total Cache mogą samodzielnie modyfikować .htaccess i nagłówki. Ręczne dopisanie kolejnych reguł może powodować konflikt albo zostać nadpisane przy zmianie ustawień wtyczki.

Jeśli korzystasz z Cloudflare, CDN nazwa.pl lub innego proxy, najpierw sprawdź jego panel. Reguły edge cache mogą mieć pierwszeństwo przed ustawieniami originu, a niektóre usługi pozwalają ustawić czas cache według rozszerzenia pliku. Po zmianie zasad wyczyść cache CDN. W przeciwnym razie przez pewien czas mogą być podawane stare odpowiedzi.

Bezpieczny podział zasobów wygląda następująco:

Obrazy, CSS, JavaScript i fonty – publiczny cache z dłuższym max-age.
Publiczne strony HTML bez personalizacji – cache o krótkim czasie życia tylko wtedy, gdy serwer poprawnie obsługuje wyjątki.
Strony zalogowanych użytkowników – private albo no-store.
Odpowiedzi z nagłówkiem Set-Cookie lub Authorization – pominięcie współdzielonego cache.

WooCommerce – które elementy muszą omijać cache?

WooCommerce intensywnie korzysta z sesji i ciasteczek. Nie wolno cache’ować strony koszyka tak samo jak wpisu na blogu. Wspólna kopia HTML może pokazać innemu klientowi zawartość koszyka, stan sesji albo dane konta.

Jeżeli po włączeniu cache produkt dodany przez jednego użytkownika pojawia się u innego, natychmiast wyłącz cache HTML dla sklepu i wyczyść wszystkie warstwy pamięci podręcznej.

W regułach CDN, wtyczki cache lub serwera wyklucz co najmniej następujące ścieżki:

/cart/ lub /koszyk/ – zawartość koszyka klienta
/checkout/ lub /zamowienie/ – proces składania zamówienia
/my-account/ lub /moje-konto/ – dane konta i historia klienta
/wp-admin/ – panel administracyjny
/wc-ajax/ – żądania AJAX WooCommerce
adresy z parametrami add-to-cart, remove_item lub undo_item

Bypass cache powinien obejmować także ciasteczka wskazujące na sesję lub stan koszyka, między innymi:

wordpress_logged_in_ i wordpress_sec_ – sesja zalogowanego użytkownika
wp_woocommerce_session_ – sesja WooCommerce
woocommerce_cart_hash i woocommerce_items_in_cart – stan koszyka
nagłówek Authorization oraz odpowiedzi wysyłające Set-Cookie

Goście mogą korzystać z cache publicznych stron sklepu, ale tylko wtedy, gdy dana odpowiedź nie zależy od sesji. Zasoby produktów, miniatury i arkusze stylów zwykle nadają się do długiego cache. HTML koszyka, checkoutu i konta powinien być generowany dynamicznie.

Jak sprawdzić, czy konfiguracja działa?

Po zapisaniu ustawień otwórz narzędzia deweloperskie przeglądarki i przejdź do zakładki Network. Wybierz dokument HTML, a następnie sprawdź sekcję Response Headers. Zwróć uwagę na Cache-Control, Set-Cookie oraz nagłówki dodawane przez CDN, na przykład status HIT, MISS, BYPASS lub DYNAMIC.

Przed wdrożeniem sprawdź następujące punkty:

Pliki CSS, JavaScript i obrazy otrzymują publiczny czas cache zgodny z przyjętą polityką.
Koszyk, checkout i konto klienta nie są zwracane jako wspólna kopia CDN.
Strona zalogowanego użytkownika nie pojawia się po wylogowaniu ani na koncie innej osoby.
Dwóch testowych użytkowników może mieć niezależny koszyk i prawidłowy stan sesji.
Po zmianie pliku statycznego nowa wersja ładuje się dzięki wersjonowaniu lub wyczyszczeniu cache.

Jeśli mimo poprawnego nagłówka odpowiedzi nadal są mieszane, sprawdź każdą warstwę osobno: wtyczkę WordPress, cache serwera, Varnish, CDN i przeglądarkę. W takiej sytuacji problem może znajdować się po stronie hostingu lub dodatkowego proxy, a nie w samym WordPressie.

Najbezpieczniejsza zasada jest prosta: agresywnie cache’uj pliki statyczne, a treści zależne od użytkownika wykluczaj z cache. W sklepie WooCommerce bezpieczeństwo sesji i koszyka ma pierwszeństwo przed zyskiem z krótszego czasu odpowiedzi.