Cloudflare-Edge-Auslieferung

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.

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.

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.

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.

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.