Filar usługowy

Wdrożenie na Cloudflare edge

Senior B2B, jurysdykcja UE, zakres ustalany per projekt.

Wycena indywidualna. Odpowiadam w ciągu jednego dnia roboczego.

Rozpocznij współpracę Headless WordPress →

Co dostarczam

WordPress na zarządzanym hostingu PHP w UE jako redakcyjny backend. Astro 5+ lub Next.js 15 jako frontend wdrożony na Cloudflare Pages. Trasy Workera dla powierzchni dynamicznej (logowanie, A/B, personalizacja na edge, transakcyjne endpointy API). R2 dla mediów, KV dla gorących odczytów, Durable Objects, gdy stan musi być blisko użytkownika.

Dlaczego edge wygrywa dla WordPressa

Klasyczny WordPress na PHP-VPS płaci koszt renderu PHP przy każdym publicznym żądaniu. Wtyczki cache pomagają, ale chybienia cache i tak trafiają w origin, a użytkownik płaci za to opóźnieniem. Przeniesienie powierzchni publicznej na edge oznacza, że średnie żądanie w ogóle nie dotyka PHP. Backend staje się systemem publikacji; front staje się systemem dostarczania.

Zmienia się również kształt kosztów. Pojedynczy VPS przeskalowany pod szczyty ruchu jest przewymiarowany na długim ogonie. Rozliczanie za żądanie dopasowuje koszt obsługi do rzeczywistej liczby żądań, a edge absorbuje skoki, które wcześniej wymuszały ręczne skalowanie.

Dla kogo to jest

  • Sklepy WooCommerce, w których mobilne Core Web Vitals ograniczają konwersję
  • Wydawcy i serwisy contentowe ze skokami ruchu w cyklu newsowym
  • Serwisy enterprise wymagające routingu danych wyłącznie w UE pod RODO + NIS2 + DORA
  • Marki multi-region, które chcą jednego origina zasilającego wiele regionów edge

Model współpracy

Senior B2B, jurysdykcja UE. Audyt, architektura, migracja, strojenie. Wycena indywidualna.

Read path na edge, write path na origin. Cache unieważniany przez webhook po tagach. Czytelnik / agent sends a request to Cloudflare Workers (edge). On cache hit the Cache na edge (per-tag) returns HTML with almost no CPU. On cache miss Workers calls REST API /wp-json/ on the Origin WordPress and renders. Editorial work happens in Block Editor + WP Admin on the origin and triggers a Webhook na publikację that invalidates relevant cache tags. Czytelnik / agent Cloudflare Workers (edge) Cache na edge (per-tag) trafienie w cache (prawie zero CPU) miss → render na edge Origin WordPress Block Editor + WP Admin REST API /wp-json/ Publikacja / zmiana slug / stan stocku Read Read Webhook na publikację Write
Read path na edge, write path na origin. Cache unieważniany przez webhook po tagach.
Edge to nie funkcja; to założenie, na którym budujesz resztę stacka.
Matthew Prince , CEO Cloudflare , Cloudflare Connect 2025 , 2025-09-15 , source

Najczęściej zadawane pytania

Dlaczego wdrażać WordPressa na Cloudflare zamiast na klasycznym hostingu PHP?

Trzy powody. Wydajność, bo frontend renderuje się z najbliższej z ponad 300 lokalizacji edge. Koszt, bo środowisko uruchomieniowe rozliczane jest za żądanie, a nie za serwer. Odporność, bo edge absorbuje skoki ruchu, które położyłyby pojedynczy VPS. Backend WordPressa nadal może działać na zarządzanym hostingu PHP; edge jest powierzchnią publiczną.

Czy Cloudflare Workers obsługuje koszyk WooCommerce?

Tak, przy odpowiedniej architekturze. Katalog i karta produktu renderują się z edge wraz z cache; koszyk i checkout działają jako SSR lub jako osobne trasy Workera, które czytają na żywo z WooCommerce. Rozdzielam te trasy świadomie, żeby strony handlowe pozostały szybkie, a strony transakcyjne poprawne.

Jak w praktyce wygląda model kosztowy Cloudflare edge?

Za żądanie, nie za serwer. Plan Workers Paid pokrywa większość produkcyjnych serwisów obsługujących do dziesiątek milionów żądań miesięcznie w przewidywalnym koszcie miesięcznym. Bandwidth dla odpowiedzi z cache nie jest mierzony. Powierzchnia kosztowa, która ma znaczenie, to żądania, milisekundy CPU per Worker oraz storage w R2 lub KV. Skaluję to na etapie architektury, nie po fakcie.

Jak to działa w jurysdykcji UE i pod RODO?

Cloudflare oferuje routing danych wyłącznie w UE w planach Enterprise, a origin WordPressa pozostaje tam, gdzie go umieścisz (zwykle hosting PHP w UE). Z punktu widzenia RODO traktuję Cloudflare jako podmiot przetwarzający, origin w UE jako lokalizację danych administratora i dokumentuję przepływ żądań w rejestrze czynności przetwarzania. Wymagania NIS2 i DORA nakładają się na tę decyzję.

Czy migracja z Vercela lub Netlify do Cloudflare jest możliwa?

Tak. Output buildu dla Astro i Next.js jest kompatybilny z Cloudflare Pages po niewielkich zmianach adaptera. Edge functions i middleware w większości przypadków portują się z Vercel Edge Runtime do Workers. Zakres migracji ustalam po godzinnym audycie; wycena indywidualna.

Dowód bez ujawniania klienta

Pracę na Cloudflare edge najłatwiej ocenić po metodzie: baseline wydajności, decyzje per route, klucze cache, przekierowania, cutover, rollback i obserwowalność po wdrożeniu.

Lektura w klastrze

Architektura i wzorce

Porównania

Migracja i harmonogramy

Zgodność i ryzyko

Materiały referencyjne

Przenieś swój front na edge

Opisz zakres i harmonogram. Odpowiadam w ciągu jednego dnia roboczego.

Skontaktuj się