Czym jest cache w WordPress?

Cache zapisuje kopię wygenerowanej treści, aby można ją było szybciej dostarczyć przy kolejnych żądaniach, bez konieczności ponownego generowania wszystkiego od zera. Dla WordPress oznacza to pomijanie wykonania PHP i zapytań do bazy danych przy powtarzających się wywołaniach strony. Strona WordPress, która potrzebuje 800 ms na wygenerowanie od zera, może być dostarczona w mniej niż 50 ms, gdy jest w cache. Cache to jedna z najbardziej wpływowych optymalizacji, jakie możesz przeprowadzić na dowolnej witrynie WordPress.

Pięć rodzajów cache w WordPress

Cache w WordPress nie jest pojedynczą rzeczą. Istnieje pięć osobnych warstw, z których każda działa w innym punkcie cyklu żądania. Zrozumienie, co robi każda warstwa, pomaga wybrać właściwą strategię cache dla Twojej witryny.

Cache przeglądarki

Cache przeglądarki to pierwsza warstwa i działa w całości na urządzeniu odwiedzającego. Gdy przeglądarka pobiera plik CSS, obraz lub plik JavaScript, zapisuje jego lokalną kopię. Przy następnym ładowaniu strony przeglądarka sprawdza, czy kopia w cache jest nadal ważna (na podstawie nagłówków Cache-Control, Expires i ETag) i całkowicie pomija pobieranie, jeśli tak jest. Eliminuje to żądania sieciowe i sprawia, że kolejne wywołania stron dla powracających odwiedzających wydają się niemal natychmiastowe.

Kontrolujesz cache przeglądarki za pomocą nagłówków odpowiedzi HTTP. Najważniejsze to:

• Cache-Control: max-age=31536000: mówi przeglądarce, aby przechowywała plik w cache przez rok (31 536 000 sekund). Używane dla wersjonowanych zasobów statycznych, które otrzymują nową nazwę pliku, gdy się zmieniają.
• Cache-Control: no-cache: przeglądarka musi sprawdzić u serwera przed użyciem kopii z cache. Serwer może odpowiedzieć "304 Not Modified", jeśli plik się nie zmienił, co oszczędza przepustowość.
• Cache-Control: no-store: przeglądarka nigdy nie może cache'ować tej odpowiedzi. Używane dla wrażliwej lub bardzo dynamicznej treści.

Cache strony

Cache strony to największy zysk wydajnościowy dla większości witryn WordPress. Oto problem, który rozwiązuje: przy każdym żądaniu strony WordPress ładuje swój core, inicjalizuje połączenie z bazą danych, wykonuje dziesiątki zapytań do bazy, przetwarza hooks wtyczek i renderuje szablony motywu. Ten cykl PHP/MySQL trwa od 200 ms do kilku sekund, w zależności od serwera i złożoności witryny. Generuje on identyczny wynik HTML dla każdego anonimowego odwiedzającego.

Cache strony zapisuje ten wynik HTML po pierwszym żądaniu. Gdy następny odwiedzający żąda tej samej strony, plik HTML z cache jest dostarczany bezpośrednio przez serwer webowy (lub nawet przez reverse proxy przed nim), całkowicie omijając WordPress, PHP i bazę danych. Różnica jest dramatyczna. Zamiast wykonywać 50-200 zapytań do bazy i uruchamiać tysiące linii PHP, serwer po prostu odczytuje plik i go wysyła.

Cache obiektów

Cache obiektów znajduje się między WordPress a bazą danych. WordPress często żąda tych samych danych wielokrotnie w ramach jednego ładowania strony i pomiędzy ładowaniami stron: opcji, metadanych użytkowników, danych wpisów, transients. Cache obiektów przechowuje te wyniki zapytań w pamięci (przy użyciu Redis lub Memcached), aby nie trafiały za każdym razem do bazy danych.

WordPress ma wbudowany cache obiektów, ale domyślnie działa on tylko w obrębie jednego żądania (nie utrzymuje się między żądaniami). Dla persystentnego cache obiektów potrzebujesz wtyczki drop-in, która łączy WordPress z Redis lub Memcached. Popularne opcje to Redis Object Cache i Object Cache Pro.

Cache obiektów jest szczególnie cenny dla witryn, które nie mogą używać pełnego cache strony, takich jak sklepy WooCommerce ze spersonalizowaną treścią, witryny członkowskie czy fora, gdzie treść często się zmienia.

Cache opcode (OPcache)

Za każdym razem, gdy PHP przetwarza skrypt, najpierw kompiluje czytelny dla człowieka kod PHP do bytecode (instrukcji czytelnych dla maszyny). Ten krok kompilacji powtarza się przy każdym żądaniu, chyba że włączony jest cache opcode. Wbudowane rozszerzenie OPcache w PHP przechowuje skompilowany bytecode we wspólnej pamięci, eliminując krok kompilacji dla kolejnych żądań.

OPcache to ustawienie na poziomie serwera, a nie coś, co konfigurujesz przez WordPress. Większość nowoczesnych środowisk hostingowych ma OPcache włączony domyślnie. Możesz to zweryfikować, sprawdzając konfigurację PHP (phpinfo) lub pytając swojego dostawcę hostingu. Sam OPcache może poprawić szybkość wykonywania PHP o 30-50%.

Cache CDN

CDN (Content Delivery Network) cache'uje Twoje statyczne zasoby na serwerach brzegowych rozproszonych po całym świecie. Gdy odwiedzający w Tokio żąda obrazu z Twojej witryny WordPress hostowanej w Amsterdamie, CDN dostarcza go z pobliskiego serwera brzegowego, zamiast kierować żądanie aż do Amsterdamu. Znacznie zmniejsza to opóźnienia dla zasobów statycznych. Niektórzy dostawcy CDN, tacy jak Cloudflare, oferują również pełny cache strony dla WordPress poprzez swoją funkcję APO. Aby uzyskać więcej szczegółów, zobacz nasz artykuł o Content Delivery Networks.

Jak cache strony działa krok po kroku

Ponieważ cache strony ma największy wpływ, oto bliższe spojrzenie na to, jak działa w praktyce:

1. Odwiedzający żąda twojadomena.com/o-nas/ po raz pierwszy.
2. WordPress przetwarza żądanie normalnie: PHP działa, baza danych jest odpytywana, szablon motywu jest renderowany, a HTML jest generowany.
3. Wtyczka cache zapisuje kopię ukończonego HTML w systemie plików (zwykle w wp-content/cache/) lub w pamięci.
4. Drugi odwiedzający żąda twojadomena.com/o-nas/.
5. Wtyczka cache przechwytuje żądanie, zanim WordPress się załaduje. Znajduje plik HTML z cache i dostarcza go bezpośrednio. PHP ledwo się uruchamia, a baza danych nie jest dotykana.
6. Gdy treść strony się zmienia (wpis jest aktualizowany, komentarz jest zatwierdzany), cache dla tej konkretnej strony jest unieważniany, a następne żądanie generuje nową kopię.

Porównanie popularnych wtyczek cache dla WordPress

Dostępnych jest wiele wtyczek cache dla WordPress. Oto najczęściej używane i jak się porównują:

• WP Rocket: wtyczka premium (od 59 USD/rok) powszechnie uważana za najbardziej przyjazne dla użytkownika rozwiązanie cache. Włącza cache strony, cache przeglądarki, kompresję GZIP i lazy loading od razu po wyjęciu z pudełka, z minimalną konfiguracją. WP Rocket obsługuje również minifikację CSS/JS, optymalizację bazy danych i integruje się z Cloudflare dla czyszczenia cache CDN. To najlepszy wybór dla właścicieli witryn, którzy chcą doskonałej wydajności bez spędzania godzin na konfiguracji.
• W3 Total Cache: darmowa wtyczka z ogromnym zakresem funkcji. Wspiera cache strony, cache obiektów (Redis, Memcached, APCu), cache przeglądarki, integrację CDN i minifikację. Wadą jest złożoność. W3 Total Cache ma dziesiątki stron ustawień, a błędna konfiguracja może zepsuć Twoją witrynę. Jest potężny, ale lepiej nadaje się dla deweloperów lub zaawansowanych użytkowników.
• WP Super Cache: darmowa wtyczka opracowana przez Automattic (firmę stojącą za WordPress.com). Skupia się na cache strony i utrzymuje prostotę. WP Super Cache generuje statyczne pliki HTML i może je dostarczać za pomocą reguł mod_rewrite, co jest bardzo szybkie. Brakuje mu zaawansowanych funkcji WP Rocket i W3 Total Cache, ale jest niezawodny i prosty w konfiguracji.
• LiteSpeed Cache: darmowa wtyczka, która zapewnia wyjątkową wydajność, gdy jest używana z serwerami webowymi LiteSpeed. Wspiera cache strony, cache obiektów, optymalizację obrazów, minifikację CSS/JS i integrację CDN. Jeśli Twój hosting używa LiteSpeed (co robi wielu shared hosts), ta wtyczka korzysta z cache na poziomie serwera, który jest szybszy niż cache oparty na PHP. Działa również na Apache i Nginx, ale z ograniczoną funkcjonalnością.

Rozwiązania cache na poziomie serwera

Poza wtyczkami WordPress cache może działać również na poziomie serwera, co często jest szybsze, ponieważ przechwytuje żądania, zanim PHP w ogóle zostanie zaangażowany:

• Varnish: cache typu reverse proxy, który znajduje się przed Twoim serwerem webowym. Varnish przechowuje pełne odpowiedzi stron w pamięci i dostarcza je bezpośrednio dla żądań z cache. Jest niezwykle szybki (czas odpowiedzi poniżej milisekundy) i jest używany przez witryny WordPress o dużym ruchu. Konfiguracja wymaga VCL (Varnish Configuration Language), co ma krzywą uczenia się.
• Nginx FastCGI Cache: jeśli Twój serwer używa Nginx (co robi wielu nowoczesnych hostów WordPress), FastCGI Cache przechowuje pełny wynik PHP i dostarcza go bezpośrednio z Nginx dla kolejnych żądań. Jest to szybsze niż jakakolwiek wtyczka cache oparta na PHP, ponieważ Nginx obsługuje żądanie całkowicie bez wywoływania PHP. Wielu managed WordPress hosts (Kinsta, GridPane, SpinupWP) używa tego podejścia.
• Redis Full-Page Cache: niektóre konfiguracje używają Redis nie tylko do cache obiektów, ale także do pełnego cache strony. Cache'owany HTML jest przechowywany w pamięci Redis, a mały skrypt PHP lub moduł Nginx dostarcza go bezpośrednio. Łączy to szybkość pamięci in-memory z elastycznością unieważniania cache opartego na kluczach.

Cache obiektów z Redis i Memcached

Dla witryn WordPress z dużym obciążeniem bazy danych persystentny cache obiektów może być transformacyjny. Oto jak porównują się dwie główne opcje:

• Redis: najpopularniejszy wybór dla WordPress. Redis przechowuje dane w pamięci i wspiera złożone typy danych (strings, hashes, lists, sets). Może persystować dane na dysk, wspiera replikację i może być używany zarówno do cache obiektów, jak i przechowywania sesji. Wtyczka Redis Object Cache to najczęstszy sposób łączenia WordPress z Redis.
• Memcached: starszy, prostszy system cache in-memory. Memcached jest szybki i lekki, ale brakuje mu persystencji danych i zaawansowanych funkcji Redis. Nadal jest używany w niektórych środowiskach hostingowych, zwłaszcza starszych.

Persystentny cache obiektów robi największą różnicę w witrynach ze złożonymi zapytaniami: sklepach WooCommerce z tysiącami produktów, społecznościach BuddyPress, sieciach multisite lub każdej witrynie, gdzie panel administracyjny WordPress wydaje się powolny.

Kiedy cache powoduje problemy

Cache nie zawsze jest prosty. Istnieją sytuacje, w których agresywny cache powoduje problemy:

• Zalogowani użytkownicy: cache strony nie powinien dostarczać cache'owanych stron zalogowanym użytkownikom, ponieważ każdy użytkownik widzi inną treść (swoją nazwę w nagłówku, pasek admina, osobisty dashboard). Wszystkie główne wtyczki cache obsługują to poprawnie domyślnie, ale niestandardowe implementacje czasami robią to źle.
• WooCommerce i e-commerce: koszyki, strony checkoutu i strony "moje konto" są dynamiczne i specyficzne dla użytkownika. Muszą być wykluczone z cache strony. WP Rocket i LiteSpeed Cache automatycznie wykluczają strony WooCommerce. W innych wtyczkach może być konieczne ręczne skonfigurowanie wykluczeń.
• Dynamiczna treść i AJAX: jeśli Twoja witryna mocno polega na treści ładowanej przez AJAX, danych w czasie rzeczywistym lub spersonalizowanych elementach (ostatnio oglądane produkty, rekomendacje specyficzne dla użytkownika), pełny cache strony może dostarczać przestarzałe treści. Rozwiązania obejmują cache fragmentów (cache wszystkiego oprócz dynamicznych części) lub ładowanie dynamicznej treści przez JavaScript po załadowaniu strony z cache.
• Witryny członkowskie: witryny z wieloma poziomami członkostwa pokazują różne treści różnym grupom użytkowników. Cache strony musi uwzględniać te warianty, albo pomijając cache dla zalogowanych użytkowników, albo utrzymując osobne wersje cache na rolę użytkownika (czego większość wtyczek nie wspiera).
• Formularze i nonces: WordPress używa nonces (number-used-once tokens) dla bezpieczeństwa w formularzach. Jeśli strona z formularzem jest cache'owana, wszyscy odwiedzający otrzymują ten sam nonce, który może wygasnąć i powodować błędy wysyłania formularzy. Wtyczki cache zwykle to obsługują, ale jest to częste źródło problemów z niestandardowymi formularzami.

Unieważnianie cache: trudna część

W informatyce istnieje słynne powiedzenie: "W informatyce są tylko dwie trudne rzeczy: unieważnianie cache i nazywanie rzeczy". Unieważnianie cache to proces czyszczenia lub aktualizowania cache'owanej treści, gdy zmieniają się dane bazowe. W WordPress oznacza to:

• Gdy publikujesz lub aktualizujesz wpis, cache dla tego wpisu, archiwów kategorii, archiwów tagów, strony głównej i każdej strony pokazującej ostatnie wpisy musi zostać wyczyszczony.
• Gdy zmieniasz ustawienia motywu, cały cache strony musi zostać wyczyszczony, ponieważ każda strona może wyglądać inaczej.
• Gdy nowy komentarz zostaje zatwierdzony, cache'owana wersja tego wpisu musi zostać zaktualizowana, aby odzwierciedlić nowy komentarz.

Dobre wtyczki cache obsługują większość tych scenariuszy automatycznie poprzez hooks WordPress. Nasłuchują zdarzeń takich jak save_post, switch_theme i wp_update_comment_count i czyszczą odpowiednie wpisy cache. Jeśli jednak masz niestandardowy kod, który modyfikuje treść bez przechodzenia przez standardowe funkcje WordPress, cache może nie zostać poprawnie unieważniony.

W razie wątpliwości większość wtyczek cache zapewnia przycisk "Wyczyść cały cache" na pasku administracyjnym WordPress. Użyj go po wprowadzeniu istotnych zmian, jeśli cache'owane strony nie odzwierciedlają Twoich aktualizacji.

Co sprawdza InspectWP

InspectWP wykrywa, czy wtyczka cache WordPress jest aktywna, szukając komentarzy HTML związanych z cache (wiele wtyczek dodaje komentarz taki jak <!-- Cached by WP Rocket --> na dole strony), nagłówków odpowiedzi (takich jak X-Cache, X-Cache-Enabled czy X-LiteSpeed-Cache) oraz znanych sygnatur wtyczek w źródle strony. Raport identyfikuje, która wtyczka cache jest w użyciu, dzięki czemu możesz zweryfikować, że Twoja konfiguracja cache działa poprawnie. Jeśli nie wykryto cache, InspectWP oznacza to jako możliwość poprawy wydajności, ponieważ cache jest jednym z najskuteczniejszych sposobów na przyspieszenie dowolnej witryny WordPress.