Cloudflare Workers i WordPress: WooCommerce serwowane na edge

#Cloudflare Workers i WordPress: WooCommerce serwowane na edge

Cloudflare Workers uruchamia JavaScript na brzegu globalnej sieci Cloudflare. WordPress uruchamia PHP na pojedynczym serwerze origin. Postawienie Workers przed WordPressem to architektura, która pozwala sklepowi WooCommerce odziedziczyć wydajność sieci edge bez przepisywania CMS-a. Kompromisy są realne i warto je nazwać wprost.

Ten artykuł osadzony jest w filarze usługi headless WordPress i zestawia się z decyzją o renderowaniu ISR vs SSR oraz ekonomią headless WordPress.

#TL;DR

• Workers obsługuje ścieżkę odczytu, WordPress obsługuje zapisy i autorstwo.
• Katalog i strony produktów WooCommerce renderowane są na edge; koszyk i checkout zostają na origin.
• Unieważnianie cache jest wyzwalane webhookiem, nie czasem.
• Cloudflare Pages ogranicza plik _redirects do 2000 reguł, planuj wokół tego.
• Plan darmowy Workers ogranicza skompresowany bundle do 1 MB; plan płatny podnosi ten limit.

#Czym właściwie jest Cloudflare Workers

Workers to runtime izolatów V8 uruchamiający JavaScript, TypeScript i WebAssembly wewnątrz sieci edge Cloudflare (strona sieci Cloudflare pokazuje listę centrów danych). To nie Node.js, nie kontener Lambda i nie miejsce do uruchamiania PHP. WordPress siedzi na swoim origin; Worker to JavaScriptowe reverse proxy postawione przed nim.

Kilka cech, które wyznaczają, co możesz, a czego nie zrobisz na Workers przed WordPressem:

• Bez PHP. Worker nie wykona wp-load.php. Może pobrać dane z /wp-json/wp/v2/posts i z /wp-json/wc/v3/products, przekształcić odpowiedź i zwrócić HTML lub JSON. Każdą uwierzytelnioną mutację obsługuje instalacja WordPress.
• CPU to budżet, który gryzie pierwszy. Plan darmowy daje około 10 ms CPU na żądanie, plan płatny podnosi to do około 30 ms, Unbound idzie wyżej. Statycznie renderowana strona produktu czytająca z Workers KV kosztuje prawie nic; pętla szablonu SSR, która agreguje cztery wywołania /wp-json/ i przepuszcza opis przez Markdown-to-HTML, potrafi przekroczyć limit planu darmowego.
• Dwie warstwy storage, dwa modele spójności. Workers KV ma spójność ostateczną i jest szybki dla odczytów na edge; zapisy potrafią propagować się globalnie do minuty, a serie zapisów są throttlowane. D1 to silnie spójny SQLite na edge. Dla WooCommerce KV nadaje się do listingów /products; live’owe liczniki stanu magazynu należą do origin WordPress lub do Durable Objects.
• Rozmiar bundle to nie iluzja. Skompresowany skrypt Workera ląduje przy 1 MB w planie darmowym i 10 MB w płatnym. Pełna aplikacja Astro lub Next.js z obrazami i bundlami lokalizacyjnymi wymaga planu płatnego.
• Sąsiednie produkty rozwiązują nakładające się problemy. Cloudflare Pages Functions siedzi w tym samym runtime i ergonomicznie pasuje do aplikacji Astro lub Next.js. Vercel Edge Functions i AWS Lambda@Edge rozwiązują podobne kształty z innymi modelami kosztowymi. Workers wygrywa, gdy WordPress już siedzi za DNS Cloudflare, a zespół chce jednej platformy do cache, WAF i renderowania.

Kod napisany pod Web Platform API (Fetch, Request, Response, Streams, Web Crypto) działa bez zmian. Kod zależny od standardowej biblioteki Node, modułów natywnych lub dostępu do systemu plików nie zadziała.

#Architektura dwuwarstwowa

We wdrożeniu Workers + WordPress odpowiedzialność dzielą dwa systemy:

Origin WordPress. Autorstwo (Block Editor, REST API, WP-CLI), operacje zapisu (tworzenie, aktualizacja, usuwanie wpisów; tworzenie zamówień; rejestracja użytkowników) oraz źródło prawdy dla treści i danych produktowych.

Edge Cloudflare Workers. Renderowanie ścieżki odczytu (generowanie HTML), agregacja API (łączenie wielu endpointów REST WordPressa w jedną odpowiedź dla frontu), cache na edge (per trasa, per tag) oraz zagadnienia przekrojowe (geo-routing, warianty A/B, przepisywanie nagłówków).

Granica jest ostra. Wszystko, co modyfikuje stan, należy do origin WordPress. Wszystko, co czyta, renderuje lub agreguje, może żyć na Workers. Koszyk i checkout siedzą na linii granicznej, bo są stanowe, ale dominuje w nich odczyt.

#Konkretne wzorce WooCommerce, które przenoszą się do Workers

Kilka wzorców Workers-przed-WooCommerce, które wdrażaliśmy lub widzieliśmy wdrożone czysto, w polskim kontekście commerce:

Edge cache dla odczytów /wp-json/. Trasa Workera dopasowuje /wp-json/wc/v3/products* i serwuje z cache, gdy klucz cache (URL plus mały zestaw nagłówków vary) jest świeży. Endpointy wrażliwe na stan magazynu jak /wp-json/wc/v3/products/<id> dostają krótszy TTL plus webhook unieważniania na akcji woocommerce_product_set_stock. Origin PHP przestaje odpowiadać na fan-out listingów produktów wywoływany przez eksportery feedu Allegro, scrapery cen i ruch botów.

Cache świadomy koszyka. Strona katalogu jest cache’owana, ale fragment minikoszyka nie. Worker odczytuje cookie wp_woocommerce_session_*, pobiera fragment koszyka z origin i sklejają odpowiedź. HTML katalogu pozostaje cache’owalny dla wszystkich anonimowych użytkowników; fragment koszyka jest per-sesja i nie cache’owany. Ten sam wzorzec mieści wstrzyknięcie statusu BLIK callbacka tak, by widok po płatności nie wisiał na cache’owanym HTML.

Transformacja obrazów na edge. Obrazy produktów WooCommerce trafiają do biblioteki mediów WordPress w pełnej rozdzielczości. Trasa Workera przed /wp-content/uploads/ skaluje, przekoduje do AVIF i cache’uje na edge. Origin przestaje uruchamiać Imagick przy każdym niecache’owanym żądaniu, co na typowym mhostingu, dhostingu czy Cyberfolks jest jednym z najgłośniejszych źródeł CPU na zajętym sklepie.

Geo-przekierowania i warianty A/B. Workers czyta cf-ipcountry i przepisuje /shop/ na /shop/cz/ dla odwiedzających z Czech, albo przypisuje cookie kohorty A/B i serwuje wariantowy HTML, bez round-tripu do PHP. Ta sama logika w WordPressie oznacza odpalenie wp-load.php żeby przeczytać is_eu_visitor() z wtyczki.

Niestandardowe reguły WAF poza domyślnymi WAF Pro. Blokuj POST na /xmlrpc.php, rate-limituj zapytania /?s= z jednego ASN, odrzucaj żądania zawierające wp-config w ścieżce. Workers daje warstwę programowalną nad zarządzanym WAF bez płacenia za sloty reguł Enterprise. Tutaj sprawdza się też normalizacja callbacków Przelewy24 z whitelistą IP bramki przed dotarciem do origin.

To, co zostaje na origin WordPress: zapisy Block Editora, tworzenie zamówień z uwierzytelnionego checkoutu, callbacki bramek płatności (BLIK, Przelewy24, refundy), sesje admina i fan-out webhooków, który wyzwala unieważnianie cache na Workerze. Serwer PHP skaluje się do wolumenu redakcyjnego plus wolumenu zamówień, a nie do anonimowego ruchu katalogowego.

#Gdzie postawić granicę

Trzy kategorie tras, trzy różne reguły renderowania:

Statyczne lub ISR na edge. Strony marketingowe, wpisy blogowe, archiwa kategorii, strony szczegółów produktu. Cache’owane agresywnie z unieważnianiem przez webhook.

SSR na edge bez cache. Koszyk, konto, dashboardy, strony checkoutu, które są spersonalizowane i sterowane sesją. Workers wykonuje render przy każdym żądaniu; WordPress dostarcza dane przez REST.

Wyłącznie origin, bez Workera. WP Admin (/wp-admin/), Block Editor i wewnętrzne endpointy REST WordPress używane do autorstwa. Konfiguracja tras Workera jawnie wyklucza je z warstwy edge.

Typowy błąd to próba przeniesienia koszyka do edge cache. Koszyk to stan per użytkownik; cache’owanie go między użytkownikami to incydent bezpieczeństwa czekający na okazję. SSR na edge to właściwy model: Worker renderuje HTML koszyka tego użytkownika, ale nie cache’uje rezultatu.

#Unieważnianie cache, element nośny

ISR na edge jest poprawne tylko wtedy, gdy unieważnianie jest poprawne. Wzorzec, który działa:

Taguj każdą cache’owaną odpowiedź. Każda renderowana strona dostaje tagi z ID wpisów, ID terminów i ID produktów WordPressa, do których się odwołuje. Cache Cloudflare Workers wspiera czyszczenie po tagach przez cache API.

Webhook na każdy zapis WordPress. Publikacja, zmiana sluga, usunięcie wpisu, aktualizacja stanu magazynu, zmiana ceny. Każda wystrzeliwuje webhook do trasy Workera, która tłumaczy “post 8421 się zmienił” na “wyczyść tag wp-post-8421” przez Cloudflare API.

Rewalidacja czasowa wyłącznie jako bezpiecznik. Okno stale-while-revalidate wynoszące 1 godzinę pokrywa awarie dostarczania webhooków. To nie jest mechanizm główny. Witryna rewalidująca co 60 sekund odbudowuje się 60 razy na godzinę dla każdej strony; przy 5000 stronach to 300000 zbędnych renderów.

Kolejność ma znaczenie: najpierw unieważnij, potem zapisz. Gdy publikacja WordPress wyzwala webhook, Worker unieważnia tag, a kolejne żądanie odbudowuje stronę z aktualnego origin. Przy odwrotnej kolejności przestarzały render wciska się do cache i utrzymuje aż do następnego unieważnienia.

#Limity, wokół których trzeba planować

Udokumentowane limity platformy Cloudflare:

• Limit _redirects w Cloudflare Pages: 2000 reguł. Powyżej tego deploy się nie udaje. Śledzimy to w pipeline build i obecnie znajdujemy się na 1600.
• Rozmiar bundle Workera: 1 MB skompresowanego w planie darmowym, więcej w planach płatnych. Trasy serwujące pełne aplikacje Astro lub Next.js wymagają planu płatnego.
• Czas CPU na żądanie: 10 ms w planie darmowym, 50 ms lub więcej w płatnych. SSR z ciężką logiką szablonu szybko przekracza pułap planu darmowego; odpowiedzi z ISR cache zużywają niemal zero CPU.
• Subżądania na żądanie: 50 w planie darmowym, więcej w płatnych. Agregacja REST WordPressa rozsiana po wielu endpointach uderza w ten limit na złożonych stronach.

Standardowa odpowiedź architektoniczna: projektuj pod plan płatny, dostarczaj na planie płatnym, plan darmowy traktuj jako sandbox developerski.

#Kształty awarii, które warto znać przed shipowaniem

Kilka konkretnych sposobów, w jakie obserwowaliśmy, jak wdrożenie Workers + WordPress się psuje albo zaskakuje zespół:

Throttling zapisów KV przy serii unieważnień. Bulk import 5000 SKU z hurtowni odpalający 5000 webhooków woocommerce_update_product. Worker tłumaczy każdy z nich na zapis KV pod kluczem cache per SKU. Przepustowość zapisów KV jest rate-limitowana per namespace, więc zapisy kolejkują się, a cache zostaje przestarzały na minuty. Naprawa polega na debounce po stronie WordPress i batchowaniu unieważnień, albo zamianie mapowania per-SKU na pojedyncze tag-purge przez Cloudflare cache API. Przy synchronizacji z feedem Allegro, gdzie batch potrafi mieć 10 tysięcy pozycji, ta różnica decyduje, czy katalog jest świeży po 30 sekundach czy po 30 minutach.

Cold start vs warm start na lokalizacjach o niskim ruchu. Izolat V8 ponownie używany między żądaniami nie ma praktycznie kosztu startu. Pierwsze żądanie do regionu po dłuższym idle płaci dodatkowe 5 do 50 ms na boot izolatu i parsowanie skryptu. Dla rzadko odwiedzanej strony lokalizacyjnej p99 wygląda gorzej niż p50. Monitory syntetyczne z wielu lokalizacji rozmazują to; RUM pokazuje jak jest naprawdę.

Pułap 1 MB bundle w planie darmowym. Pełna aplikacja Next.js 15 z adapterem Cloudflare, react-server-dom, kilkoma bundlami lokalizacji i klientem REST WooCommerce z łatwością przekracza 1 MB skompresowanego. Deploy nie udaje się przy uploadzie, nie w runtime. Planuj plan płatny (10 MB) albo rozdziel renderowanie na wiele skryptów Workera.

Fan-out subżądań na stronach agregowanych. Strona kategorii pobierająca termin, produkty, kategorie powiązane, breadcrumb i menu uderza w pięć endpointów /wp-json/. Plan darmowy zatrzymuje subżądania na 50 per wywołanie Workera, płatny na 1000. Warstwy agregacji prekomponujące odpowiedź po stronie WordPress albo pojedynczy endpoint GraphQL przez WPGraphQL trzymają licznik pod kontrolą.

Awarie dostarczenia webhooków zostawiające przestarzały cache. WordPress wystrzeliwuje webhook w akcji shutdown; jeśli worker PHP-FPM stimeoutuje albo sieć siądzie, webhook nigdy nie dociera do Workera. Zwłaszcza dla webhooków refundu Przelewy24, gdzie potwierdzenie operatora przychodzi z opóźnieniem, brak backstopu oznacza, że strona produktu pokazuje “w magazynie” mimo że refund zwiększył stan. Tag-based stale-while-revalidate na 1 godzinę łapie to; bez bezpiecznika przestarzały render trzyma się aż do następnego ręcznego purge.

#Kompatybilność z Astro i Next.js

Według Tech Radaru Q3 2026 zarówno Astro 5+, jak i Next.js 15 dostarczają oficjalne adaptery Cloudflare. Adapter Astro kompiluje trasy statyczne i SSR do Workers; adapter Next.js robi to samo z App Router. Oba produkują artefakt deploya, który działa na Cloudflare Pages z Workers pod spodem.

Wybór między nimi opisany jest w matrycy decyzyjnej Next.js vs Astro. Dla sklepu WooCommerce mocno opartego na treści Astro jest zwykle właściwym domyślnym wyborem, bo model statyczny czysto mapuje się na katalog. Dla wdrożenia mocniej aplikacyjnego (konto, dashboard, złożona personalizacja) model server components Next.js ma przewagę ergonomiczną.

Tak czy inaczej, origin WordPress pozostaje niezmieniony. Workers + WordPress to wzorzec architektoniczny, a nie wybór frameworka.

#Jak wygląda współpraca z agencją

Migracja Workers + WordPress w usłudze headless WordPress WPPoland przebiega w czterech fazach.

Faza pierwsza, audyt. Inwentaryzacja instalacji WordPress (wtyczki, kod własny, powierzchnia REST API, liczba użytkowników admin), pomiar bazowego TTFB i TTI, identyfikacja wszystkiego, co zależy od renderowania PHP w czasie żądania (funkcje motywu, page buildery, personalizacja po stronie serwera).

Faza druga, scaffolding REST i webhooków. Dodanie lub utwardzenie endpointów REST WordPressa, których potrzebuje front. Postawienie wystrzałów webhooków przy publikacji, zmianie sluga i (dla commerce) zmianie stanu magazynu. Weryfikacja ścieżki dostarczania webhooków na domenie staging.

Faza trzecia, build frontu i cutover. Zbudowanie frontu Astro lub Next.js, wdrożenie na Cloudflare Pages, równoległe uruchomienie z legacy frontem na okno pomiarowe, następnie przełączenie przez DNS lub proxy Cloudflare. Obsługa sitemap i kanonicznych URL według naszej listy wzorców SEO jest niepodlegająca negocjacji.

Faza czwarta, observability i tuning. Logi edge (Cloudflare Logpush), logi origin (serwer WordPress) i testy syntetyczne. Strojenie TTL cache i wzorców unieważniania tagów na podstawie profilu ruchu produkcyjnego.

Nie obiecujemy konkretnych liczb z góry, bo TTFB i TTI zależą od ładunku wtyczek origin WordPress, frameworka frontowego i sieci użytkownika. Publikujemy protokoły i przeprowadzamy pomiar: zobacz nasz scaffold benchmarków, do którego sami się zobowiązujemy metodologicznie.

#Gdzie to się wpisuje

Ten filar artykułu osadzony jest w klastrze usługi headless WordPress. Dla wyboru frameworka zobacz matrycę decyzyjną Next.js vs Astro. Dla wyboru renderowania per trasa zobacz decyzję ISR vs SSR. Dla ryzyk migracji SEO zobacz listę wzorców SEO headless WordPress. Dla ramy kosztowej zobacz ekonomię headless WordPress 2026.