Cloudflare dla WordPressa – reguły i edge-cache WooCommerce

Założenia i cele konfiguracji

Celem konfiguracji Cloudflare dla WordPressa jest połączenie szybkiego TTFB, stabilnego LCP i pełnej poprawności sesji. Dla gości chcemy agresywnego cache HTML na krawędzi – dla zalogowanych i procesów zakupowych twardego omijania cache. Dzięki temu strona pozostaje szybka bez ryzyka „przecieku” stanu użytkownika.

Podstawą jest jasny podział ruchu: dokumenty publiczne i assety do cache, ścieżki wrażliwe i odpowiedzi z cookies poza cache. Drugi filar to normalizacja klucza cache – ignorujemy szum marketingowy w parametrach, a zostawiamy tylko te, które realnie zmieniają HTML. Trzeci to bezpieczniki po stronie originu – poprawne nagłówki Cache-Control i kontrola Set-Cookie.

Szablon reguł cache i nagłówków

Zacznij od reguł, które działają globalnie, a następnie doprecyzuj wyjątki.

1) „Cache everything” dla HTML gości
– Zakres: dokumenty HTML poza wyjątkami.
– Edge TTL 20–60 minut, Browser TTL 5–10 minut – włącz stale-while-revalidate dla płynnych odświeżeń.
– Normalizacja klucza cache: ignoruj utm_*, gclid, fbclid i inne tagi kampanii. Zostaw paginację, sortowanie i filtry, gdy zmieniają treść.

2) Zasoby statyczne
– Obrazy, CSS, JS, czcionki – długie TTL na krawędzi i w przeglądarce, najlepiej 7–30 dni.
– Wersjonowanie nazw plików rozwiązuje problem odświeżania bez czyszczenia cache.
– Włącz kompresję Brotli i minifikację – zysk bez ryzyka dla logiki aplikacji.

3) Nagłówki po stronie originu
– Publiczne strony: Cache-Control: public, max-age=300, stale-while-revalidate=30.
– Odpowiedzi, które ustawiają lub konsumują stan użytkownika: Cache-Control: no-store.
– Czcionki z innych domen – pamiętaj o crossorigin i typie MIME, by uniknąć podwójnych pobrań.

4) Usprawnienia bezdotykowe
– Early Hints 103 – wskazówki Link dla krytycznego CSS, fontu i obrazu LCP.
– preconnect tylko do kluczowych hostów – ostrożnie, by nie marnować gniazd.
– Opcjonalnie APO dla WordPressa – gdy chcesz „plug-and-play” cache HTML dla gości.

Wyjątki i edge-cache dla WooCommerce

WooCommerce intensywnie korzysta z sesji i cookies – dlatego potrzebuje twardych wyjątków. Zasada jest prosta: koszyk, checkout, konto i operacje AJAX nigdy nie trafiają do cache.

1) Krytyczne ścieżki do ominięcia
– /cart*, /checkout*, /my-account*, /wp-admin*, /wc-ajax*.
– Bypass dla metod innych niż GET oraz gdy obecny jest nagłówek Authorization.
– Wyklucz URL z parametrami akcyjnymi: ?add-to-cart=*, ?remove_item=*, ?undo_item=*.

2) Cookies wymuszające omijanie cache
– wordpress_logged_in_, wordpress_sec_ – zalogowani.
– wp_woocommerce_session_ – identyfikator sesji sklepu.
– woocommerce_cart_hash, woocommerce_items_in_cart – stan koszyka.
– woocommerce_recently_viewed – personalizacja list.
Jeśli którykolwiek z tych prefiksów jest ustawiony – dokument HTML ma być generowany dynamicznie.

3) TTL i CBS dla sklepów
– HTML gości: edge TTL 30 minut + stale-while-revalidate.
– Obrazy produktowe i miniatury: długie TTL i wersjonowanie – największy zysk w CWV.
– Nigdy nie cache’uj odpowiedzi ustawiających Set-Cookie dla wymienionych prefiksów.

4) Testy poprawności
– Sprawdź CF-Cache-Status – koszyk i checkout muszą mieć BYPASS lub DYNAMIC.
– W narzędziach deweloperskich dodaj do koszyka jako dwóch różnych użytkowników – upewnij się, że stan się nie miesza.
– Monitoruj, czy zapytania do /wc-ajax/* omijają cache i wracają z prawidłowymi nagłówkami.

Bezpieczeństwo i niezawodność

Ochrona aplikacji idzie w parze z wydajnością. Zabezpiecz panele i punkty wrażliwe – inaczej zysk z cache zje ruch niechciany.

• Rate Limiting na /wp-login.php i XML-RPC – ogranicz próby logowania i bruteforce.
• WAF z predefiniowanymi zestawami reguł – blokuj skanery i typowe wektory ataków.
• Turnstile w formularzach publicznych – mniej spamu przy zerowym tarciu dla użytkowników.
• TLS i HSTS – wymuś HTTPS wszędzie, wyłącz przestarzałe protokoły, ustaw Minimum TLS 1.2 lub wyżej.
• „Argo” i „Tiered Cache” – szybsze połączenia do originu i mniej kosztownych missów, zwłaszcza przy ruchu globalnym.
• Cache Bypass Safeguards – zakazuj cache dla odpowiedzi z Set-Cookie i gdy obecny Authorization.

Monitoring, testy i rozwiązywanie problemów

Bez stałego pomiaru trudno utrzymać jakość. Zrób krótki plan obserwacji i checklistę kontroli.

• KPI po wdrożeniu – TTFB dokumentu, LCP na p75, hit ratio HTML dla gości, błędy checkoutu.
• RUM – taguj odsłony flagą „guest vs logged-in” i porównuj LCP dla obu segmentów.
• Analiza parametrów – ogranicz fragmentację cache, ignorując utm_*, gclid, fbclid.
• Najczęstsze pułapki: mieszanie stanu koszyka przez błędny cache HTML, podwójne pobrania fontów bez crossorigin, brak efektu Early Hints przez zbyt długą listę Link.
• Procedura rollback – pojedyncza zmiana naraz, logi CF-Cache-Status, testy A/B na wybranych ścieżkach, a dopiero potem roll-out globalny.

Podsumowaniem

Idealna konfiguracja Cloudflare dla WordPressa to selektywny cache HTML dla gości, jasne wyjątki dla WooCommerce i twarde bezpieczniki po stronie originu. Najpierw ustaw reguły „cache everything” z normalizacją parametrów, potem dodaj bypass na kluczowe cookies i ścieżki, a na końcu włącz usprawnienia jak Early Hints i długie TTL dla assetów. Połącz to z WAF, rate limiting i stałym monitoringiem – uzyskasz szybkie LCP i niskie TTFB bez ryzyka naruszenia sesji.