Service-Pillar

Cloudflare-Edge-Deployment

Senior B2B, EU-Jurisdiktion, Umfang pro Projekt definiert.

Preisgestaltung individuell. Ich antworte innerhalb eines Werktags.

Engagement starten Headless WordPress →

Was ich liefere

WordPress auf einem Managed-PHP-Host in der EU als redaktionelles Backend. Astro 5+ oder Next.js 15 als Front-End, deployed auf Cloudflare Pages. Worker-Routes für die dynamische Oberfläche (Auth, A/B, Edge-Personalisierung, transaktionale API-Endpoints). R2 für Medien, KV für heiße Reads, Durable Objects, wenn State nahe am Nutzer leben muss.

Warum das Edge bei WordPress gewinnt

Ein klassisches PHP-on-VPS-WordPress zahlt den PHP-Render-Cost bei jedem öffentlichen Request. Caching-Plugins helfen, aber Cache Misses treffen weiterhin den Origin und der Nutzer zahlt mit Latenz. Das Verschieben der öffentlichen Oberfläche aufs Edge bedeutet, dass der durchschnittliche Request PHP gar nicht mehr berührt. Das Backend wird zum Publishing-System; das Front-End wird zum Delivery-System.

Auch die Kostenform ändert sich. Ein einzelner VPS, dimensioniert für Trafficspitzen, ist im Long Tail überdimensioniert. Pro-Request-Abrechnung passt die Auslieferungskosten an die tatsächliche Request-Zahl an, während das Edge Spitzen abfängt, die zuvor manuelles Skalieren ausgelöst haben.

Für wen das passt

  • WooCommerce-Shops, in denen mobile Core Web Vitals die Conversion begrenzen
  • Publisher und Content-Sites mit Trafficspitzen in Newszyklen
  • Enterprise-Sites, die EU-only Data Routing unter DSGVO + NIS2 + DORA brauchen
  • Multi-Region-Marken, die einen Origin viele Edge-Regionen versorgen lassen wollen

Engagement-Modell

Senior-B2B-Verträge in EU-Jurisdiktion. Audit, Architektur, Migration, Tuning. Preisgestaltung individuell.

Read-Path am Edge, Write-Path am Origin. Cache wird per Webhook nach Tags invalidiert. Leser / Agent sends a request to Cloudflare Workers (Edge). On cache hit the Edge-Cache (pro Tag) returns HTML with almost no CPU. On cache miss Workers calls REST API /wp-json/ on the WordPress-Origin and renders. Editorial work happens in Block Editor + WP Admin on the origin and triggers a Webhook bei Veröffentlichung that invalidates relevant cache tags. Leser / Agent Cloudflare Workers (Edge) Edge-Cache (pro Tag) Cache-Treffer (fast keine CPU) Cache-Miss → Render am Edge WordPress-Origin Block Editor + WP Admin REST API /wp-json/ Veröffentlichung / Slug-Änderung / Bestand Read Read Webhook bei Veröffentlichung Write
Read-Path am Edge, Write-Path am Origin. Cache wird per Webhook nach Tags invalidiert.
Das Edge ist kein Feature; es ist die Annahme, auf der man den Rest des Stacks baut.
Matthew Prince , CEO von Cloudflare , Cloudflare Connect 2025 , 2025-09-15 , source

Häufig gestellte Fragen

Warum WordPress auf Cloudflare statt auf einem klassischen PHP-Host deployen?

Drei Gründe. Performance, weil der Front-End-Render vom nächsten von über 300 Edge-Standorten kommt. Kosten, weil die Laufzeit pro Request statt pro Server abgerechnet wird. Resilienz, weil das Edge Trafficspitzen abfängt, die einen einzelnen VPS umwerfen würden. Das WordPress-Backend kann weiterhin auf einem Managed-PHP-Host laufen; das Edge ist die öffentliche Oberfläche.

Unterstützt Cloudflare Workers den WooCommerce-Checkout?

Ja, mit der richtigen Architektur. Katalog und Produktdetail rendern vom Edge mit Cache; Warenkorb und Checkout laufen als SSR oder als separate Worker-Routes, die live aus WooCommerce lesen. Ich trenne die Routes bewusst, damit kommerzielle Seiten schnell und transaktionale Seiten korrekt bleiben.

Wie sieht das Cloudflare-Edge-Kostenmodell in der Praxis aus?

Pro Request, nicht pro Server. Der Workers-Paid-Plan deckt die meisten Produktivsysteme mit unter zweistelligen Millionen Requests pro Monat zu vorhersehbaren monatlichen Kosten ab. Bandwidth ist für gecachte Antworten unbegrenzt. Die kostenrelevante Oberfläche sind Requests, CPU-Millisekunden pro Worker und Storage in R2 oder KV. Das dimensioniere ich in der Architektur, nicht im Nachgang.

Wie funktioniert das mit EU-Jurisdiktion und DSGVO?

Cloudflare bietet EU-only Data Routing in Enterprise-Plänen, und der WordPress-Origin bleibt dort, wo Sie ihn ablegen (in der Regel ein PHP-Host in der EU). Aus DSGVO-Sicht behandle ich Cloudflare als Auftragsverarbeiter, den EU-Origin als Datenort des Verantwortlichen und dokumentiere den Request-Flow im Verzeichnis der Verarbeitungstätigkeiten. NIS2- und DORA-Kontrollen kommen auf diese Entscheidung obendrauf.

Können Sie ein Vercel- oder Netlify-Deployment auf Cloudflare migrieren?

Ja. Der Build-Output für Astro und Next.js ist mit Cloudflare Pages nach kleineren Adapter-Anpassungen kompatibel. Edge Functions und Middleware portieren in den meisten Fällen von Vercel Edge Runtime zu Workers. Den Migrationsumfang lege ich nach einem einstündigen Audit fest; Preisgestaltung individuell.

Proof ohne Kundennamen

Cloudflare-Edge-Arbeit lässt sich am besten über die Methode prüfen: Baseline-Messung, Entscheidungen pro Route, Cache-Keys, Redirects, Cutover, Rollback und Observability nach dem Launch.

Cluster-Lektüre

Architektur und Patterns

Vergleiche

Migration und Zeitpläne

Compliance und Risiko

Referenz

Bringen Sie Ihr Front-End ans Edge

Beschreiben Sie Umfang und Zeitplan. Ich antworte innerhalb eines Werktags.

Kontakt aufnehmen