Wydajność strony internetowej to dziś jeden z kluczowych czynników wpływających zarówno na doświadczenie użytkownika, jak i widoczność w wyszukiwarkach. Nawet niewielkie opóźnienia po stronie serwera mogą wpływać na czas ładowania strony oraz ogólną płynność jej działania. Dlatego coraz większą rolę odgrywają mechanizmy cache, które pozwalają skrócić czas odpowiedzi i odciążyć backend (czyli ograniczyć pracę PHP i bazy danych). Jednym z takich rozwiązań jest MAx Cache dostępny w ramach AccelerateWP.
Czy jednak jego wpływ jest rzeczywiście odczuwalny w praktyce? Kiedy przynosi realne korzyści, a kiedy jego działanie jest ograniczone? I jak wypada w porównaniu do standardowego cache HTML generowanego przez AccelerateWP? W dalszej części artykułu pokazujemy konkretne testy i wyniki, które pozwolą odpowiedzieć na te pytania.
Czym jest MAx Cache od AccelerateWP
AccelerateWP to zestaw zaawansowanych funkcji optymalizacji wydajności WordPressa, dostępny bezpłatnie w cPanel dla naszych klientów hostingowych. Więcej o nim pisaliśmy w artykule:AccelerateWP – zaawansowane funkcje optymalizacji wydajności WordPressa.
MAx Cache to nowa funkcja wchodząca w skład AccelerateWP, wprowadzona w pierwszym kwartale 2026 roku. Jest to mechanizm cache działający na poziomie serwera. Jego głównym celem jest przyspieszenie czasu odpowiedzi poprzez serwowanie gotowego, statycznego HTML bez angażowania PHP, a co za tym idzie również bez wykonywania zapytań do bazy danych przy każdym żądaniu. Dzięki temu powinniśmy doświadczyć:
- zmniejszenia obciążenia serwera,
- przyspieszenia strony opartej na WordPress za sprawą skrócenia czasu TTFB.
MAx Cache wykrywa wygenerowany HTML przez warstwę cache WordPressa (np. AccelerateWP i innych wtyczek typu cache) i serwuje go bezpośrednio użytkownikowi, co daje natychmiastowy efekt wydajnościowy. Mechanizm działa najskuteczniej na stronach z małą liczbą elementów dynamicznych (formularze, koszyk, logowanie).
Gdzie włączyć MAx Cache
MAx Cache włączamy bezpośrednio w panelu WordPressa, w ramach wtyczki AccelerateWP. W tym celu:
- Zaloguj się do kokpitu WordPressa.
- Przejdź do menu AccelerateWP i Add-ons (Dodatki).
- Włącz suwak MAx Cache.
Po włączeniu MAx Cache mechanizm od razu zaczyna działać dla wszystkich wylogowanych użytkowników odwiedzających stronę, serwując gotowy, statyczny HTML bez generowania go dynamicznie przez PHP i bez odpytywania bazy danych.
Metodologia testów
W celu sprawdzenia skuteczności MAx Cache wykonujemy testy przed i po jego włączeniu na dwóch różnych stronach naszych klientów, które funkcjonują aktywnie od kilku lat:
- statyczna strona WordPress,
- sklep oparty na WooCommerce
Sprawdzamy:
- wpływ MAx Cache na wydajność WordPressa,
- czy eliminuje opóźnienia związane z PHP – testy wymagają, aby użytkownik był wylogowany, a mechanizm działa najlepiej na stronach bez dynamicznych elementów (np. formularzy, koszyka, logowania).
Narzędzie użyte do pomiarów – wyjaśnienie
Do sprawdzenia wpływu MAx Cache na wydajność WordPressa użyliśmy ogólnodostępnego narzędzia Chrome Dev Tools (Narzędzia deweloperskie). Przy jego pomocy sprawdziliśmy TTFB (Time To First Byte), czyli czas, jaki upływa od momentu wysłania żądania przez przeglądarkę do otrzymania pierwszego bajtu odpowiedzi od serwera.
Aby dostać się do narzędzia, w przeglądarce Chrome wciśnij F12 lub kliknij prawym przyciskiem myszy na stronie i wybierz Zbadaj.
W narzędziu tym interesuje nas zakładka Network (Sieć), gdzie po odświeżeniu strony dla wybranego żądania (Zakładka “Nazwa”) sprawdzamy:
- Nagłówki odpowiedzi (Headers) – informacje o serwerze, cache i innych elementach wskazujących na wykorzystanie MAx Cache,
- Czas (Timing) – w tym TTFB, pozwalający ocenić, czy gotowy HTML został dostarczony natychmiast, bez dodatkowego generowania po stronie PHP.
Podczas testów upewniamy się, że checkbox “Wyłącz pamięć podręczną” nie jest zaznaczony.
Dzięki temu w prosty sposób możemy zweryfikować efekt działania cache dla wybranej strony.
Oczekiwany rezultat testów
Po włączeniu MAx Cache spodziewamy się dwóch efektów:
- Pojawienie się nagłówków “Cache-Control: public, max-age=3600” i “ETag” w formacie heksadecymalnym (hex-hex)
- spadku TTFB
Nagłówek Cache-Control: public, max-age=3600 oznacza, że:
- odpowiedź może być cache’owana przez serwer proxy NGINX,
- zawartość jest ważna przez 3600 sekund (1 godzinę),
- serwer nie musi angażować PHP przy każdym żądaniu.
W praktyce: gotowy HTML jest serwowany bezpośrednio z cache. To realnie wpływa na mniej pracy po stronie serwera, brak uruchamiania PHP przy każdym wejściu i szybszy TTFB.
Z kolei nagłówek ETag odpowiada za coś innego niż samo cache’owanie — służy do sprawdzania, czy zawartość strony się zmieniła. To nic innego jak identyfikator konkretnej wersji wygenerowanego HTML. Jeśli treść strony pozostaje taka sama, wartość ETag również się nie zmienia.
W praktyce działa to tak, że przy kolejnym wejściu przeglądarka nie musi pobierać całej strony od nowa. Zamiast tego wysyła do serwera zapytanie z informacją: „mam już wersję o takim identyfikatorze — czy coś się zmieniło?”. Jeśli nie, serwer odpowiada kodem 304 Not Modified i nie wysyła ponownie HTML-a.
Efektem jest:
- brak zbędnego transferu danych,
- szybsze odświeżenia strony,
- mniejsze obciążenie serwera,
W kontekście MAx Cache ma to dodatkowe znaczenie, ponieważ serwer operuje na gotowym, statycznym HTML, może przypisać mu konkretny identyfikator i efektywnie zarządzać jego aktualnością. Dzięki temu przeglądarka nie tylko korzysta z cache, ale też wie dokładnie, kiedy musi pobrać nową wersję strony.
Testy strony internetowej opartej na WordPressie
Przeprowadziliśmy testy wydajności strony klienta, która funkcjonuje aktywnie od kilku lat, wykonując pomiary w trzech wariantach: bez cache (przed włączeniem AccelerateWP), z włączonym AccelerateWP (bez MAx Cache) oraz po aktywacji MAx Cache.
Test został wykonany wyłącznie na stronie głównej.
Próba z wyłączonym cache
Przy pierwszym załadowaniu strony, przy braku cache, czas oczekiwania na odpowiedź serwera (TTFB) wyniósł około 140,65 ms, co wskazuje na konieczność wygenerowania strony po stronie serwera (udział PHP i bazy danych przy obsłudze żądania).
Próba po włączeniu AccelerateWP
Kolejno włączyliśmy AccelerateWP i odświeżyliśmy stronę. Po ponownym załadowaniu strony czas oczekiwania na odpowiedź serwera (TTFB) spadł do około 72,31 ms, co wskazuje na wykorzystanie mechanizmu cache i znaczące ograniczenie czasu generowania strony po stronie serwera.
Próba z włączonym AccelerateWP i MAx Cache
Finalnie włączyliśmy MAx Cache i ponownie odświeżyliśmy stronę. Po kilku kolejnych odświeżeniach (wykonaliśmy kilka prób) czas oczekiwania na odpowiedź serwera (TTFB) ustabilizował się na poziomie około 47,23 ms.
W nagłówkach odpowiedzi pojawiły się również oczekiwane wartości:
- Cache-Control: public, max-age=3600
- ETag w formacie heksadecymalnym
W porównaniu do poprzednich etapów testu oznacza to:
- spadek TTFB z ~140,65 ms (brak cache) do ~47,23 ms – ok. 66% szybciej,
- spadek z ~72,31 ms (AccelerateWP) do ~47,23 ms – ok. 35% szybciej.
Wynik ten pokazuje dodatkowy efekt optymalizacji po stronie serwera po aktywacji MAx Cache, który jeszcze bardziej skraca czas odpowiedzi względem standardowego cache AccelerateWP.
Jednocześnie należy zaznaczyć, że różnica na poziomie kilkunastu – kilkudziesięciu milisekund (np. ~72 ms a ~47 ms) jest praktycznie niewyczuwalna dla użytkownika końcowego i nie wpływa bezpośrednio na odbiór strony.
Z punktu widzenia SEO ma to jednak znaczenie – niższy TTFB jest pozytywnym sygnałem dla Google, jednak przy już bardzo dobrych wartościach różnica na poziomie kilkudziesięciu milisekund nie przekłada się na istotną zmianę w ocenie strony.
Aby zweryfikować, czy ta optymalizacja ma realne znaczenie w bardziej wymagających warunkach, w kolejnym kroku przeprowadziliśmy test obciążeniowy.
Test obciążeniowy – K6 Grafana
W testach obciążeniowych wykonanych przy pomocy narzędzia k6 Grafana (50 równoczesnych użytkowników) nie zaobserwowaliśmy istotnej różnicy w czasie TTFB pomiędzy konfiguracją z samym AccelerateWP a konfiguracją z włączonym MAx Cache.
Oznacza to, że w tym scenariuszu dodatkowa warstwa cache po stronie NGINX nie przynosi mierzalnej poprawy wydajności pod obciążeniem, a serwer już wcześniej obsługiwał zapytania bardzo sprawnie.
W praktyce wskazuje to, że:
- standardowy cache AccelerateWP jest w tym przypadku wystarczający,
- MAx Cache nie wprowadza dodatkowej przewagi przy tej konkretnej konfiguracji i typie strony.
Testy sklepu opartego na WordPress z WooCommerce
W przypadku sklepu WooCommerce testy wydajności wymagają odpowiedniego doboru podstron, ponieważ część serwisu opiera się na elementach dynamicznych zależnych od użytkownika. MAx Cache działa najefektywniej na treściach statycznych, dlatego w testach uwzględniamy przede wszystkim stronę główną oraz stronę kategorii produktów.
Strona główna stanowi najbardziej „życiowy” scenariusz, jednak zawiera elementy dynamiczne, co może ograniczać wpływ cache.
Z kolei strona kategorii zawiera więcej elementów do przetworzenia niż standardowa strona WordPress, a jednocześnie ma stosunkowo niewiele elementów dynamicznych zależnych od użytkownika, co pozwala założyć, że to właśnie tutaj mechanizmy cache mogą przynieść najbardziej widoczny efekt.
Próba z wyłączonym cache
Strona główna
Przy pierwszym załadowaniu strony, bez aktywnego cache, TTFB wynosi około 585 ms, co oznacza konieczność pełnego wygenerowania strony przez PHP i bazę danych. To typowy wynik dla dynamicznej strony WooCommerce bez włączonego cache.
Strona kategorii
W przypadku strony kategorii TTFB wynosi około 609 ms, co wskazuje na podobny poziom obciążenia backendu i brak wykorzystania cache. Strona kategorii, mimo że bardziej statyczna niż strona główna, nadal wymaga pełnego przetworzenia po stronie serwera.
Próba po włączeniu AccelerateWP
Strona główna
Po włączeniu AccelerateWP, TTFB spadł do około 101 ms. To pokazuje wyraźny efekt wykorzystania cache HTML generowanego przez WordPressa. Strona jest serwowana znacznie szybciej, jednak nadal może dochodzić do częściowego przetwarzania po stronie PHP, szczególnie w przypadku elementów dynamicznych.
Strona kategorii
Średni TTFB wynosi około 72 ms. W związku z tym wynik jest wyraźnie niższy niż bez cache, co potwierdza realny wpływ optymalizacji.
Próba z włączonym AccelerateWP i MAx Cache
Strona główna
Po włączeniu MAx Cache TTFB spadł do około 67 ms. W porównaniu do braku cache (~585 ms) oznacza to poprawę o około 88%, natomiast względem samego AccelerateWP (~100 ms) jest to dodatkowy spadek o około 33%. Pokazuje to, że MAx Cache może jeszcze dodatkowo skrócić czas odpowiedzi serwera.
Strona kategorii
Średni TTFB wynosi około 34 ms, ze sporadycznymi wzrostami do około 67 ms. W porównaniu do braku cache (~609 ms) oznacza to poprawę rzędu ~94%, a względem samego AccelerateWP (~72 ms) dodatkowe skrócenie czasu odpowiedzi o około 50%. W tym przypadku efekt MAx Cache jest bardziej widoczny, co wynika z bardziej statycznego charakteru strony kategorii.
Test obciążeniowy – K6 Grafana
Ponownie wykonaliśmy testy wydajnościowe dla sklepu WooCommerce, które potwierdziły wcześniejsze wyniki – uzyskane wartości były praktycznie identyczne. W testach obciążeniowych nie zaobserwowaliśmy wpływu MAx Cache na TTFB strony głównej, co oznacza, że w tym scenariuszu mechanizm ten nie przynosi dodatkowej poprawy pod obciążeniem.
Wniosek
Bazując na opracowanych obserwacjach, włączenie MAx Cache przynosi dodatkową redukcję TTFB względem samego AccelerateWP, szczególnie na podstronach o bardziej statycznej strukturze, takich jak kategorie produktów.
Jednocześnie, przy już bardzo dobrych wynikach osiąganych przez AccelerateWP, uzyskana poprawa ma głównie charakter techniczny i nie przekłada się na zauważalną różnicę dla użytkownika końcowego.
Dodatkowo w testach obciążeniowych dla sklepu WooCommerce nie zaobserwowaliśmy poprawy TTFB po włączeniu MAx Cache.
Różnica między MAx Cache, Redis Object Cache i statycznym cache
Na zakończenie warto jeszcze rozróżnić różne mechanizmy cache, aby lepiej zrozumieć, czym jest MAx Cache i na jakim etapie przetwarzania strony działa.
W praktyce mamy kilka warstw cache:
- Cache przeglądarki (browser cache) – działa po stronie użytkownika (w jego przeglądarce) i pozwala nie pobierać ponownie tych samych zasobów, np. obrazków czy stylów strony. Dzięki temu kolejne wejścia na stronę są szybsze.
- Cache serwera WWW (NGINX Reverse Proxy) – działa na poziomie serwera, czyli miejsca, gdzie znajduje się Twoja strona. NGINX to oprogramowanie, które obsługuje zapytania użytkowników – może ono zapamiętać gotową odpowiedź i odesłać ją bez konieczności „uruchamiania” WordPressa.
- MAx Cache – mechanizm działający na poziomie serwera WWW, który wykrywa gotowy HTML strony (czyli finalną wersję strony wygenerowaną przez WordPress) i serwuje go bezpośrednio użytkownikowi, pomijając tzw. backend, czyli PHP i bazę danych.
- Statyczny cache WordPress (np. AccelerateWP, WP Rocket) – zapisuje gotową wersję strony (HTML), dzięki czemu WordPress nie musi jej za każdym razem generować od nowa. To właśnie ten mechanizm odpowiada za największy skok wydajności po włączeniu cache.
- Redis Object Cache – działa głębiej, na poziomie bazy danych. Zapamiętuje wyniki zapytań, dzięki czemu WordPress nie musi ich ponownie wykonywać. Przyspiesza to działanie strony, ale nie eliminuje całkowicie pracy backendu.
Każda z tych warstw optymalizuje inny etap działania strony – od bazy danych, przez backend (czyli proces generowania strony przez WordPress), aż po serwer i przeglądarkę użytkownika. Dzięki temu mechanizmy cache mogą się uzupełniać, jednak ich realny wpływ zależy od typu strony oraz obecności elementów dynamicznych.
Podsumowanie
MAx Cache to dodatkowa warstwa cache po stronie serwera, która stanowi dalszą optymalizację względem samego AccelerateWP.
W naszych testach dla standardowej strony WordPress skróciliśmy TTFB z ~140 ms do ~47 ms (ok. 66%), a względem samego AccelerateWP (~72 ms) o dodatkowe ~35%.
W przypadku WooCommerce uzyskaliśmy poprawę z ~585 ms do ~67 ms na stronie głównej (ok. 88%) oraz z ~609 ms do ~34 ms na stronie kategorii (ok. 94%), co oznacza dodatkowe skrócenie względem AccelerateWP odpowiednio o ~33% i ~50%.
MAx Cache pozwala jeszcze bardziej zoptymalizować czas odpowiedzi serwera i wykorzystać pełen potencjał cache na poziomie infrastruktury, szczególnie w przypadku podstron, które mogą być serwowane jako gotowy HTML. W połączeniu z AccelerateWP stanowi spójny, wielowarstwowy mechanizm optymalizacji, który zwiększa wydajność i stabilność działania strony.
Spodobały Ci się opisane narzędzia? Przetestuj za darmo nasz hosting ULTRA i zobacz, jak wiele możesz zyskać na wydajności swojej strony – wykorzystaj w praktyce możliwości AccelerateWP, Redis Object Cache i MAx Cache.
Już od kilku lat zajmuję się planowaniem, koordynacją i realizacją działań marketingowych w MSERWIS.pl i Domeny.tv. Jestem odpowiedzialny za promowanie usług, produktów i oprogramowań mojej firmy. Aby jak najlepiej zrozumieć ich funkcje i zalety współpracuję z zespołem programistów i Biurem Obsługi Klienta. Wykorzystuję różnorodne taktyki i kanały marketingowe, żeby dotrzeć do potencjalnych klientów i przekonać ich do zakupu lub subskrypcji. Moje działania obejmują m.in. tworzenie kampanii marketingowych, pisanie materiałów marketingowych, zarządzanie mediami społecznościowymi oraz marketingiem e-mailowym i analizowanie rynku w celu zrozumienia potrzeb i preferencji docelowych odbiorców. Rozumiem technologię i potrafią przekazywać złożone koncepcje techniczne odbiorcom nietechnicznym. Mam doświadczenie w obszarach takich jak content marketing, SEO i generowaniu leadów. Potrafię skutecznie mierzyć i analizować wyniki działań marketingowych, aby stale ulepszać swoje strategie.
Polub nas na Facebooku
Komentarze