Mikrobuforowanie NGINX dla WordPressa: milisekundy zamiast sekund

Mikrobuforowanie NGINX skraca czas ładowania WordPressa z całych sekund do milisekund, ponieważ serwer internetowy buforuje gotowe odpowiedzi HTML na kilka sekund, odciążając w ten sposób PHP-FPM oraz bazę danych. Pokażę, jak to krótkie okno buforowania sprawdza się w praktyce, jakie zasady zapewniają bezpieczeństwo WordPressa oraz jak można uzyskać zauważalnie szybsze odpowiedzi w okresach szczytowego ruchu.

Punkty centralne

Z góry Podsumuję najważniejsze kwestie, abyś mógł przeczytać kolejne akapity, skupiając się na tym, co dla Ciebie istotne.

• Milisekundy zamiast sekund: krótkie czasy TTL wynoszące od 1 do 10 s zapewniają niezwykle szybkie wyświetlanie stron, które często się powtarzają.
• Ulga w przypadku backendu: mniej żądań kierowanych do PHP-FPM i bazy danych, znacznie mniejsze obciążenie serwera.
• Zasady ochrona: pliki cookie, dane logowania i koszyki nie są zapisywane w pamięci podręcznej.
• Skalowanie w codziennej pracy: szczyty ruchu przebiegają bez zakłóceń, a liczba przekroczeń limitu czasu i błędów 502 wyraźnie spada.
• Blok konstrukcyjny W konfiguracji: w połączeniu z OPcache, Gzip/Brotli i odpowiednim dostrojeniem bazy danych uzyskujemy szybkość działania.

Jak działa technicznie mikrocaching

NGINX zapisuje kod HTML wygenerowany przez WordPress w pamięci podręcznej FastCGI i dostarcza identyczne kolejne żądania bezpośrednio z pamięci, bez ponownego obciążania PHP-FPM i bazy danych. Stosuję w tym celu bardzo krótkie czasy przechowywania, ponieważ aktualność treści pozostaje ważna, podczas gdy wskaźnik trafień w pamięci podręcznej gwałtownie rośnie w okresach największego natężenia ruchu. Efekt widać od razu: identyczne żądania trafiają do pamięci podręcznej i są przesyłane w ciągu milisekund. W praktyce instalacje WordPressa można przyspieszyć wielokrotnie; często przytaczany przykład mówi o nawet 400-krotnym przyspieszeniu, jeśli poprawnie ustawiono kilka dyrektyw (źródło: NGINX (blog). Najważniejsze jest to, że rejestruję wyłącznie odpowiedzi, które można zapisać w pamięci podręcznej, a strony zawierające dane wrażliwe celowo pomijam.

Dlaczego WordPress odnosi szczególne korzyści

WordPress generuje wiele identycznych odpowiedzi jedna po drugiej, na przykład dla stron głównych, wpisów i stron kategorii, zwłaszcza tuż po opublikowaniu. Właśnie w tym momencie wkracza mikrobuforowanie: identyczne wywołania są obsługiwane bez obciążania PHP i znacznie odciążają bazę danych. Wynikiem tego są krótsze czasy Time-to-First-Byte oraz mniejsze szczyty obciążenia procesora, co znacznie poprawia komfort użytkowania. Dodatkowo stawiam na OPcache, prawidłową kompresję multimediów i wydajne renderowanie motywów, ponieważ te działania sumują się. Osoby, które chcą pogłębić swoją wiedzę na ten temat, znajdą dobre wprowadzenie pod adresem Pamięć podręczna NGINX dla WordPressa, co wyraźnie pokazuje jego praktyczną użyteczność.

Konfiguracja: myślenie krok po kroku

Start jest strefą pamięci podręcznej zawierającą ścieżkę, klucz i rozmiar; przechowuje ona odpowiedzi z przepływu FastCGI. W bloku serwera określam, że buforowane są wyłącznie żądania GET i HEAD, podczas gdy żądania POST są pomijane. Pliki cookie, takie jak wordpress_logged_in lub woocommerce_items_in_cart, ustawiam jako kryteria wykluczenia, aby zalogowani użytkownicy zawsze otrzymywali aktualne, spersonalizowane treści. Aby zapewnić przejrzystość, wysyłam nagłówek X-Cache z wartością HIT, MISS lub BYPASS, dzięki czemu natychmiast widzę status w przeglądarce lub w logach. Dodatkowo ograniczam rozmiar obiektu, aby oszczędzać pamięć, i zezwalam na żądania warunkowe (Conditional Requests), aby nagłówki HTTP wzajemnie się uzupełniały.

Zasady dotyczące pamięci podręcznej: co na pewno pozostaje wykluczone

Loginy, Nigdy nie buforuję panelu administracyjnego, strony kasy, koszyka ani stron profilowych, ponieważ zawierają one dane sesji lub treści osobowe. Wykluczam również nonce, podglądy i strony wyszukiwania, ponieważ często generują one indywidualne odpowiedzi. Parametry zapytań, takie jak „add-to-cart” czy „preview”, są przetwarzane bezpośrednio przez PHP, aby uniknąć powstawania błędnych kopii. Niektóre wtyczki ustawiają własne pliki cookie; sprawdzam ich nazwy z wyprzedzeniem i zapisuję je jako reguły pominięcia. Dzięki temu strona pozostaje w pełni funkcjonalna, ale wyświetla anonimowe strony standardowe z ogromną szybkością.

TTL, świeżość i „okno“

Krótki Czas TTL wynoszący od 1 do 10 sekund stanowi sedno mikro-cachingowania, ponieważ umiejętnie łączy aktualność z szybkością. Wybieram ten przedział w zależności od rodzaju treści: gorąco dyskutowane posty wymagają krótszych czasów niż statyczne strony docelowe. Kto chce zaplanować to dokładniej, może zdefiniować niewielkie „okno“, które pozwala na krótką ponowną walidację i wyrównuje szczyty obciążenia. Szczegółowe uzasadnienie idealnego okna zawiera ten artykuł na stronie Okno optymalizacji pamięci podręcznej, który traktuję jako punkt wyjścia do refleksji. Poniższa tabela przedstawia popularne profile i ich działanie.

TTL	Użycie	Przewaga	Wskazówka
1–2 s	Najświeższe wiadomości, posty, które stały się hitem w sieci	Bardzo aktualne treści, wysoki wskaźnik odwiedzin w okresach szczytowego ruchu	W backelu nadal często dochodzi do przebudowy
3–5 s	Strona główna, Kategorie	Dobra równowaga między tempem a świeżością	Idealne rozwiązanie dla często odwiedzanych stron WP
6–10 s	Strony produktów i strony stałe	Bardzo niskie obciążenie serwera	Aktualizacje trwają zaledwie kilka sekund
15–30 s	Treści rzadko aktualizowane	Maksymalne odciążenie	Używać tylko wtedy, gdy świeżość jest w porządku

Monitorowanie i analiza nagłówków

Nagłówek Mówię prawdę: dzięki X-Cache, Age i Cache-Control rozpoznaję trafienia, czasy wygaśnięcia i próby obejścia. W narzędziach programistycznych przeglądarki od razu widzę, czy strona została wyświetlona jako trafienie (HIT) i jak stary jest ten wpis. Po stronie serwera rejestruję status w pliku access_log, aby zidentyfikować punkty newralgiczne i precyzyjnie dostosować reguły. Dodatkowo zwracam uwagę na Nagłówek Cache-Control, aby pamięć podręczna przeglądarki i serwery proxy działały prawidłowo. Regularne pomiary pozwalają wykrywać marnotrawstwo, unikać błędów i zapewnić niezawodną szybkość działania platformy.

Skalowanie w przypadku szczytów obciążenia

Ruch uliczny rzadko rozkłada się równomiernie; szczyty natężenia ruchu często pojawiają się w przedziałach czasowych rzędu sekund. Technologia microcaching wyłapuje te fale, ponieważ identyczne wywołania stron są natychmiast pobierane z pamięci podręcznej, omijając kosztowne ścieżki backendowe. Dzięki temu spada wskaźnik błędów, czas TTFB znacznie się skraca, a strona pozostaje dostępna dla czytelników. Nawet niewielkie instancje VPS radzą sobie w ten sposób ze szczytami związanymi z newsletterami lub gwałtownymi wzrostami ruchu w mediach społecznościowych, nie ulegając przeciążeniu. Dla redakcji, sklepów internetowych wprowadzających nowe produkty na rynek lub prowadzących kampanie marketingowe jest to kluczowy czynnik.

Współpraca z wtyczkami i CDN

Plugin-Pamięci podręczne często działają na poziomie PHP; mikropamięć podręczna znajduje się przed nimi i ma największy wpływ na wydajność. Dlatego ustawiam czas działania pamięci podręcznej wtyczek na krótszy niż TTL w NGINX lub pomijam ją w przypadku standardowych stron, aby żadne podwójne warstwy nie zużywały niepotrzebnie energii. Sieć CDN może dostarczać obrazy, pliki CSS i JS, podczas gdy mikropamięć podręczna przyspiesza ładowanie HTML; takie połączenie obejmuje oba poziomy. Buforowanie w przeglądarce za pomocą ETag, Last-Modified oraz Gzip/Brotli dopełnia ten obraz i zmniejsza wykorzystanie przepustowości. Ważne: haki czyszczenia (purge hooks) łączą publikacje lub zmiany produktów z ukierunkowanym unieważnieniem pamięci podręcznej.

Sytuacje skrajne i bezpieczeństwo

Dane osobowe Ściśle blokuję niektóre treści, takie jak strony kont, podsumowania zamówień czy treści powiązane z sesją. W przypadku WooCommerce wyraźnie rozdzielam strony kategorii w środowisku produkcyjnym (możliwe do buforowania) od koszyka, kasy i konta (omijanie). Pominięte są również podglądy, działania chronione kodami nonce oraz ścieżki administracyjne. Przeprowadzam ukierunkowane testy z zalogowanymi i anonimowymi użytkownikami, a także na urządzeniach z plikami cookie i bez nich. Dzięki temu strona działa poprawnie, szybko i jest zgodna z przepisami.

Praktyczne aspekty hostingu i koszty

Koszty serwera szybko rosną, gdy każde żądanie angażuje PHP i bazę danych; mikrocaching pozwala tu zaoszczędzić pieniądze. Wiele stron radzi sobie zaskakująco dobrze z 1–4 rdzeniami procesora i 2–8 GB pamięci RAM, o ile mikrobuforowanie działa prawidłowo. Zamiast podnosić cenę abonamentu o 20–50 € miesięcznie, ograniczam liczbę żądań wysyłanych do zaplecza i utrzymuję krótkie czasy odpowiedzi. Jeśli chodzi o porównania i rekomendacje, serwis webhoster.de często zajmuje pierwsze miejsce w testach dotyczących wydajności WordPressa, zwłaszcza tam, gdzie liczy się szybkość odpowiedzi i zachowanie pod obciążeniem. Ci, którzy chcą jeszcze poprawić wyniki, stawiają na szybszą pamięć masową NVMe, aktualne wersje OpenSSL/Brotli oraz regularne kopie zapasowe.

Konfiguracja praktyczna: konfiguracja minimalna z regułami ochronnymi

Beton Dyrektywy pomagają szybko rozpocząć pracę. Poniższy przykład przedstawia praktyczną konfigurację podstawową z funkcją Cache-Lock, wykluczeniami plików cookie, opcją BYPASS oraz krótkimi wartościami TTL wyłącznie dla plików HTML.

# Globalna strefa pamięci podręcznej (dostosuj rozmiar i czas bezczynności)
fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=MICRO:32m
                   max_size=2g inactive=60s use_temp_path=off;

# Tylko GET/HEAD podlegają buforowaniu
map $request_method $cacheable_method {
    default 0;
    GET     1;
    HEAD    1;
}

# Pliki cookie/parametry omijające pamięć podręczną
map $http_cookie $skip_cache {
    default 0;
    ~*(wordpress_logged_in|wordpress_sec)   1;
    ~*(wp-postpass|comment_author) 1;
    ~*(woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_) 1;
}

# Opcjonalne nagłówki omijające (np. dla haków czyszczenia)
map $http_x_microcache_bypass $header_bypass {
    default 0;
    1 1;
}

# Proste pomijanie parametrów śledzenia (zapobiega fragmentacji)
map $args $has_tracking {
    default 0;
    ~*(^|&)(utm_[^&]+|fbclid|gclid|mc_cid|mc_eid)= 1;
}

# Łączenie warunków
map "$cacheable_method$skip_cache$header_bypass$has_tracking" $bypass {
    default 1;   # Domyślnie: bypass
    1000   0;    # GET/HEAD, brak plików cookie, brak nagłówków, brak trackerów: cache
}

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

 # Blokada pamięci podręcznej chroni przed nadmiernym obciążeniem
    fastcgi_cache_lock on;
    fastcgi_cache_lock_age 5s;
    fastcgi_cache_lock_timeout 10s;

 # Lokalizacja PHP
    location ~ \.php$ {
 include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_pass unix:/run/php/php-fpm.sock;

        # Krótkie buforowanie tylko HTML
 set $is_html 0;
 if ($sent_http_content_type ~* "text/html") { set $is_html 1; }

 fastcgi_cache MICRO;
        fastcgi_cache_key "$scheme$request_method$host$uri$is_args$args";

 fastcgi_no_cache     $bypass;
        fastcgi_cache_bypass $bypass;

 # Profil TTL
 fastcgi_cache_valid 200 3s;
 fastcgi_cache_valid 301 302 10s;
        fastcgi_cache_valid any 0s;

 # Wyświetlanie nieaktualnych danych w przypadku błędów
 fastcgi_cache_use_stale error timeout updating http_500 http_503;

        # Przejrzystość odpowiedzi
 add_header X-Cache $upstream_cache_status always;

 # Brak buforowania dużych odpowiedzi
 fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
    }

 # Ustawienia domyślne WordPressa
    location / {
 try_files $uri $uri/ /index.php?$args;
    }

    # Nigdy nie buforować
    location = /wp-login.php { access_log off; }
    location ~* ^/(wp-admin|cart|checkout|my-account|account) { add_header X-Cache BYPASS always; }
}

Uwaga: Parametry śledzenia są tutaj obsługiwane poprzez obejście. Jeśli chcesz je usunąć, skorzystaj z przekierowań kanonicznych po stronie serwera lub zaawansowanej normalizacji; w przypadku mikrobuforowania zazwyczaj wystarcza proste obejście, które pozwala uniknąć fragmentacji kluczy.

Strategia kluczowa i normalizacja

Czysty klucz pamięci podręcznej zapobiega powtórzeniom. Kieruję się ścieżką oraz stanami zapytań, które faktycznie zmieniają zawartość. Przykłady:

• Należy zachować spójność w stosowaniu ukośników końcowych (WordPress reguluje to za pomocą permalinków/try_files).
• Zezwól tylko na istotne parametry (np. s= dla wyszukiwania, paged= dla paginacji); wszystko inne omija pamięć podręczną.
• Klasy urządzeń i języki należy uwzględniać w kluczu tylko wtedy, gdy kod HTML rzeczywiście się różni (np. w przypadku testów A/B po stronie serwera lub wielojęzycznych motywów bez prefiksu w adresie URL).

Im mniej wariantów generuje ta sama strona, tym wyższy wskaźnik trafień. W przypadku stron zindywidualizowanych pod kątem międzynarodowym, wykorzystujących prefiksy językowe (/de/, /en/), wystarczy ścieżka; w przypadku podejścia opartego na plikach cookie plik cookie musi służyć jako obejście.

Ochrona przed stampede i strategie dotyczące stale

fastcgi_cache_lock zapobiega uruchomieniu dziesiątek równoczesnych wywołań PHP po upływie czasu TTL. NGINX pozwala na „rekalibrację“ dokładnie jednego żądania i obsługuje równoległe żądania przy użyciu ostatniego ważnego obiektu (aktualizacja). Ponadto stwierdza się, że fastcgi_cache_use_stale strona jest dostępna nawet w przypadku błędów (przekroczenie limitu czasu, 500/503). W praktyce pozwala to znacznie ograniczyć liczbę błędów 502/504 w okresach największego natężenia ruchu.

Czyszczenie i aktualizacja treści w praktyce

Microcaching funkcjonuje w oparciu o krótkie czasy życia (TTL), dzięki czemu klasyczne czyszczenie pamięci cache jest rzadziej konieczne. W przypadku redakcji lub sklepów, które oczekują „natychmiastowej“ widoczności, sprawdziły się trzy sposoby:

• Ciche czyszczenie za pomocą kolektora obejściowego: Hook WordPressa (np. podczas publikacji/aktualizacji) wysyła za pośrednictwem protokołu HTTP żądanie do adresu URL z nagłówkiem X-Microcache-Bypass: 1. Żądania te omijają pamięć podręczną i natychmiast „rozgrzewają“ nowy kod HTML.
• Ukierunkowane pomijanie poszczególnych adresów URL: W przypadku szczególnie ważnych stron (strona główna, określone kategorie) można tymczasowo ustawić BYPASS za pomocą mapy NGINX (flaga w pliku/zmienna), który wygaśnie po kilku sekundach.
• Usuwanie na podstawie plików: To możliwe, ale podatne na błędy, ponieważ klucze są przechowywane w postaci skrótów. Korzystam z tego tylko wtedy, gdy jest to absolutnie konieczne i przy zastosowaniu jasnej strategii tworzenia ścieżek.

Ważne jest to, że mikrosekundowe czasy TTL wynoszące od 3 do 10 s praktycznie zawsze gwarantują aktualność danych bez konieczności stosowania skomplikowanej infrastruktury oczyszczającej.

Rejestrowanie, wskaźniki i testy obciążeniowe

Pomiar uwidacznia efekty. Rozszerzony format logu dokumentuje statusy i czasy:

log_format micro '$remote_addr - $host "$request" $status '
 'rt=$request_time urt=$upstream_response_time '
                 'u_cache=$upstream_cache_status bytes=$body_bytes_sent';

access_log /var/log/nginx/access.micro.log micro;

Po wdrożeniu sprawdzam rozkład wyników HIT/MISS/BYPASS, średni czas odpowiedzi (request_time) oraz różnice między wywołaniami „ciepłymi” a „zimnymi”. W testach obciążeniowych (np. z krótkimi wzrostami obciążenia i szczytami) widać, że TTFB pozostaje stabilnie niski pod obciążeniem, a wariancja maleje. W przypadku zauważenia odchyleń należy dostosować TTL, reguły Bypass lub ograniczyć zbędne warianty w kluczu.

WooCommerce: praktyczne wyjątki

Sklepy Znacznie korzystają z funkcji Microcache w przypadku stron kategorii, list produktów, stron szczegółowych produktów (bez spersonalizowanych bloków) oraz treści redakcyjnych. Absolutnie niedopuszczalne są koszyk, proces realizacji zamówienia, konto oraz listy porównawcze. Typowe reguły dotyczące plików cookie:

• Obejście w: woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*
• Obejście w: logged_in, wordpress_sec, wp-postpass_* (wpisy dotyczące haseł)
• Obejście w przypadku: parametrów „add-to-cart” oraz akcji zabezpieczonych za pomocą nonce’a

Na stronach produktów sprawdzam dodatkowo, czy dynamiczne widżety dotyczące stanów magazynowych i cen są odświeżane za pomocą AJAX. Jeśli tak, kod HTML pozostaje możliwy do buforowania, podczas gdy dane są pobierane na bieżąco przez API – to czysty podział zapewniający maksymalną szybkość.

Zasoby i układ pamięci

Strefa pamięci podręcznej a pamięć ma bezpośredni wpływ na stabilność. Kilka praktycznych wskazówek:

• keys_zone: 16–64 MB wystarczy na dziesiątki tysięcy kluczy; lepiej jednak przewidzieć nieco rezerwy.
• max_size: Należy wyraźnie ograniczyć rozmiar pamięci podręcznej; w przypadku NVMe 1–4 GB często wystarcza na mikropamięć podręczną.
• nieaktywny: Rzadko używane obiekty należy przytrzymać przez 30–120 s; w przypadku mikroskrytek wystarczy 60 s.
• tmpfs: W przypadku bardzo małych witryn, które wymagają wyjątkowo niskiego opóźnienia, dobrym rozwiązaniem może być tmpfs (pamięć RAM); należy jednak pamiętać, że pamięć RAM jest ograniczona i ulotna.

Jeśli chodzi o PHP-FPM, dzięki pamięci podręcznej mogę ustawić niższą wartość pm.max_children i zmniejszyć obciążenie pamięci – często jest to jeden z najszybszych sposobów na „obniżenie kosztów“ na serwerach pracujących na pełnych obrotach.

Typowe problemy i ich rozwiązywanie

Często Źródła błędów można wcześnie wykryć, przeprowadzając kilka kontroli:

• Nieprawidłowe pliki cookie w pamięci podręcznej: Gdy strony z nagłówkami Set-Cookie są buforowane, anonimowi użytkownicy otrzymują resztki sesji. Rozwiązanie: fastcgi_no_cache/fastcgi_cache_bypass w przypadku $upstream_http_set_cookie lub określonych plików cookie.
• Problemy związane z nonce i podglądem: preview=true, customize_changeset_uuid, _wpnonce – koniecznie pominąć.
• Pętle przekierowań: 301/302 – buforuj tylko na krótko lub celowo wykluczaj; sprawdź reguły kanoniczne i reguły dotyczące ukośnika końcowego.
• Strony wyszukiwania (/?s=…): Zazwyczaj ustawia się to indywidualnie; domyślnie ustawiam BYPASS.
• xmlrpc.php, wp-cron.php: Nie buforować i w razie potrzeby ograniczać; często powodują niepotrzebne obciążenie.
• Zawartość mieszana W przypadku zmiany protokołu z HTTP na HTTPS: klucz zawiera schemat $; upewnij się, że strona działa konsekwentnie przez HTTPS.
• Brakujące nagłówki Vary W przypadku zasobów: nie ma to znaczenia dla kodu HTML, ale jest przydatne w przypadku plików statycznych; mimo to obowiązuje zasada: kod HTML pochodzi z pamięci podręcznej FastCGI, a zasoby – najlepiej z sieci CDN.

Precyzyjne dostosowanie do rzeczywistych procesów redakcyjnych

Redakcje Pracuję falami: szkice, zapowiedzi, publikacje. Microcaching nie może mi w tym przeszkadzać. Stosuję następujące zasady:

• Krótszy czas TTL dla strony głównej i archiwów kategorii (3–5 s), dłuższe dla statycznych stron docelowych (8–10 s).
• Ocieplenie ważnych ścieżek (Strona główna, Najpopularniejsze kategorie, 3–5 najnowszych artykułów) bezpośrednio po zdarzeniach publikacji za pomocą nagłówka bypass, aby czytelnicy natychmiast otrzymali nowy kod HTML.
• Stale-if-error działamy w sposób świadomy i aktywny, aby zapewnić dostępność nawet w przypadku krótkotrwałych zakłóceń w pracy bazy danych.

W ten sposób wygoda edycji i wydajność płynnie się łączą – bez konieczności klikania przez autorów przycisku „Oczyść pamięć podręczną“.

Lista kontrolna: Od zera do wymiernego przyspieszenia

Po pierwsze Tworzę zmienną `fastcgi_cache_path` i strefę, a następnie aktywuję `fastcgi_cache` w odpowiednim bloku serwera. Następnie definiuję klucze pamięci podręcznej, TTL i nagłówki, ustawiam X-Cache oraz dbam o prawidłowe wykluczenia za pomocą fastcgi_no_cache/skip. Potem sprawdzam żądania GET/HEAD, pliki cookie BYPASS oraz parametry zapytania, aby chronić spersonalizowane odpowiedzi. Podczas działania monitoruję wskaźniki HIT/MISS/AGE, dostosowuję TTL i strategię kluczy oraz sprawdzam efekty w testach obciążeniowych. Na koniec powiązuję publikacje z zdarzeniami czyszczenia pamięci podręcznej, aby zmiany były szybko widoczne.

Aby zabrać

Microcaching znacznie przyspiesza działanie WordPressa, ponieważ identyczne wywołania stron pozostają w pamięci podręcznej NGINX przez kilka sekund i są ponownie dostarczane bez użycia PHP-FPM. Metoda ta odciąża bazę danych, zmniejsza liczbę błędów w okresach szczytowego obciążenia, a jednocześnie zapewnia aktualność treści. Zasady dotyczące plików cookie, logowania i koszyków zakupowych zapewniają zachowanie funkcjonalności, podczas gdy standardowe strony czerpią z tego maksymalne korzyści. W połączeniu z OPcache, skompresowanymi zasobami i odpowiednią konfiguracją bazy danych uzyskuje się odczuwalny wzrost szybkości działania. Kto mądrze dobierze okres przechowywania w pamięci podręcznej, ten zmierzy efekt w milisekundach zamiast w sekundach i znacznie zwiększy zadowolenie użytkowników.