Strony publiczne warto cachować w page cache lub CDN, a spersonalizowane konta, koszyki i callbacki wykluczyć. Cache obiektowego należy używać do powtarzalnych obliczeń i zapytań, a nie jako zamiennika ich optymalizacji. Proszę zdefiniować cache key i unieważnianie przy zmianie treści, ceny lub uprawnień oraz testować zarówno anonimowego, jak i zalogowanego użytkownika.
Cache w WordPressie przyspiesza stronę, ponieważ nie przechodzi wielokrotnie całej ścieżki od PHP i bazy danych po zdalne pliki. Istnieje jednak kilka warstw: page cache, cache obiektów, opcode cache, CDN i przeglądarka. Każda przechowuje inny wynik i ma inne zasady ważności. Dwie wtyczki konfigurujące tę samą warstwę mogą powodować konflikt, a brak unieważniania sprawia, że wyświetla się nieaktualna cena lub treść.
Prawidłowy projekt zaczyna się od klasyfikacji stron na publiczne, spersonalizowane i wrażliwe. Publiczny artykuł można bezpiecznie udostępniać wielu odwiedzającym, konto czy koszyk już nie. Klucz cache musi uwzględniać język, walutę lub wymaganą rolę, a po zmianie danych odpowiedni wpis musi zostać usunięty. Wydajność weryfikuje się razem z funkcjonalnością, a nie tylko na podstawie wskaźnika trafień.
Rozróżnij poszczególne warstwy cache
Page cache przechowuje gotową odpowiedź HTML i omija dużą część WordPressa. Cache obiektowy przechowuje wyniki operacji na danych między żądaniami. Opcode cache przyspiesza wykonywanie kodu PHP, a przeglądarka zapisuje pliki statyczne zgodnie z nagłówkami. CDN może cache’ować obrazy, CSS lub całe publiczne strony na brzegu sieci.
Przed włączeniem nowej wtyczki proszę sprawdzić, co zapewnia już hosting lub proxy. Podwójny page cache utrudnia czyszczenie i diagnostykę. Należy udokumentować właściciela każdej warstwy, ścieżkę administracyjną i awaryjny purge. Wyczyszczenie wszystkiego może chwilowo obciążyć serwer, dlatego przy dużej stronie lepiej stosować selektywną inwalidację.
Sklasyfikuj treści publiczne i spersonalizowane
Artykuły, usługi i publiczne archiwa są dobrymi kandydatami, jeśli ich wynik nie zależy od tożsamości użytkownika. Panel administracyjny, podgląd szkicu, konto, koszyk, kasa, nonce i callback płatności nie powinny być serwowane z publicznej pamięci cache. Formularz na stronie w cache musi generować lub odświeżać tokeny bezpieczeństwa w obsługiwany sposób.
Zalogowany redaktor może widzieć pasek narzędzi, link edycji i niepubliczną treść, dlatego cache rozróżnia ciasteczka lub jest pomijany dla takich sesji. Strona członkowska potrzebuje dokładniejszego klucza według roli lub uprawnienia, ale liczba wariantów nie może eksplodować w nieskończoność. Najpierw proszę ograniczyć personalizację strony publicznej.
- Publiczny anonimowy HTML
- Wykluczone konta i transakcje
- Oddzielne sesje zalogowanych użytkowników
- Żadnych sekretów w kluczu cache ani w logu
Zaprojektuj klucz cache i unieważnianie
Klucz może obejmować URL, język, walutę, urządzenie – tylko jeśli treść faktycznie się różni – oraz inne kontrolowane warianty. Należy ignorować parametry kampanii, które nie zmieniają treści, aby nie tworzyły tysięcy kopii. Z kolei parametr filtra zmieniający wynik nie może otrzymać HTML innej kombinacji. Normalizację należy przetestować również z wartościami zakodowanymi.
Przy zapisie artykułu proszę wyczyścić jego stronę szczegółów, odpowiednie archiwum, sekcję strony głównej i sitemap zgodnie z zależnościami. Zmiana globalnego nagłówka może wpłynąć na całą stronę, dlatego wymaga szerszej invalidacji. Cena lub stan magazynowy wymagają krótkiego czasu ważności albo zdarzenia z integracji. Czasowy TTL jest zabezpieczeniem, a nie zamiennikiem precyzyjnego purge po krytycznej zmianie.
Używaj cache obiektowego dla odpowiednich danych
Trwały cache obiektowy pomaga przy powtarzalnych zapytaniach i obliczeniach, jeśli mają stabilny klucz i rozsądny czas życia. Nie powinien ratować zapytania, które wczytuje wszystkie rekordy bez limitu. Monitoruj hit rate, pamięć, evictions i opóźnienie magazynu. Nieprawidłowo skonfigurowany zdalny serwer cache może być wolniejszy niż lokalna baza danych.
Klucze należy umieszczać w przestrzeniach nazw według witryny i środowiska, zwłaszcza w przypadku multisite lub współdzielonego Redis. Produkcja i staging nie mogą odczytywać tych samych obiektów. Przy wdrożeniu zmieniającym format danych proszę podnieść wersję przestrzeni nazw lub przeprowadzić bezpieczną inwalidację. Nigdy nie należy zapisywać wrażliwej odpowiedzi jako obiektu publicznego bez kontroli dostępu.
- Stabilny klucz z przestrzenią nazw
- Odpowiedni czas życia i rozmiar
- Oddzielne środowiska
- Monitorowanie pamięci i opróżniania
Testuj cache jako funkcjonalny element systemu
Proszę przetestować pierwszą i powtórną wizytę, okno anonimowe i zalogowane, dwa języki, urządzenie mobilne, formularz i podgląd. Należy zmienić artykuł, menu, cenę lub uprawnienie i zmierzyć czas do uzyskania poprawnego wyniku. Warto sprawdzić nagłówki cache, Age, Vary oraz status CDN. Nigdy nie należy testować wyłącznie jako administrator, dla którego cache jest często pomijany.
W razie błędu proszę postępować od przeglądarki przez CDN i serwerowy page cache aż po cache obiektów, zamiast czyścić wszystko naraz. W ten sposób ustalą Państwo, która warstwa jest winna. Po aktualizacji wtyczki cache należy przeprowadzić test regresji ścieżek krytycznych. Runbook powinien opisywać czyszczenie selektywne, pełny purge, oczekiwane chwilowe obciążenie oraz kontakt do hostingu.
Najczęstsze pytania
Dlaczego po zmianie WordPress nadal wyświetla starą treść?
Starą odpowiedź może przechowywać przeglądarka, CDN, page cache lub cache obiektowy. Proszę sprawdzić nagłówki i czyścić warstwy stopniowo. Następnie proszę poprawić unieważnianie przy konkretnej zmianie, aby redaktor nie musiał za każdym razem czyścić wszystkiego.
Czy mogę cachować koszyk WooCommerce?
Proszę nie stosować publicznego page cache dla koszyka i kasy. Katalog można cache’ować z unieważnianiem przy zmianie ceny i stanu magazynowego. Konkretne cookies, fragmenty i endpointy proszę skonfigurować zgodnie z WooCommerce, hostingiem i używanymi rozszerzeniami.
Czy więcej warstw cache jest zawsze szybsze?
Nie. Każda warstwa dodaje reguły, unieważnianie i możliwy dodatkowy krok sieciowy. Należy używać tylko warstw o mierzalnej korzyści i z jasno określonym właścicielem. Zdublowane mechanizmy page cache mogą pogorszyć niezawodność.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
