Cloudflare Workers vs. Pages: Der Unterschied, der wichtig ist, bevor Sie sich entscheiden

Die meisten Tutorials zu Cloudflare Workers und Pages machen den falschen Vergleich. Es stellt die beiden als direkte Konkurrenten dar, als müsste man sich zwischen einem Framework und einem anderen entscheiden. Worker und Pages lösen unterschiedliche Probleme auf unterschiedlichen Ebenen – und wenn man sich entscheidet, ohne diesen Unterschied zu verstehen, entstehen Architekturen, die teuer sind oder eine Umgestaltung in sechs Monaten erfordern.

Was jeder einzelne tatsächlich ist

Workers ist eine Computerplattform. Sie schreiben Code, stellen ihn mit wrangler deploy bereit und dieser Code läuft auf V8-Isolaten, die über das Cloudflare-Netzwerk verteilt sind – derzeit an mehr als 300 Points of Presence. Das Ausführungsmodell ist ereignisgesteuert: Jede HTTP-Anfrage, jede Warteschlangennachricht, jeder Cron-Trigger oder jeder E-Mail-Handler generiert einen Aufruf. Der Kaltstart liegt unter 1 ms, da V8-Isolate im Gegensatz zu Containern, die von Grund auf neu beginnen, denselben Prozess nutzen.

Pages ist eine Hosting-Plattform. Der zentrale Fall ist: Sie haben eine Website oder ein SPA, Sie erstellen git push, Cloudflare führt Ihren Build aus (npm run build, Hugo, Astro, was auch immer) und die resultierenden statischen Assets werden über das globale CDN verteilt. Anfragen für diese Assets – HTML, JS, CSS, Bilder – werden direkt vom CDN bedient, ohne dass eine Rechenlaufzeit erforderlich ist.

Pages verfügt auch über Pages-Funktionen, bei denen es sich um Worker-Skripte handelt, die über die Verzeichniskonvention (/functions) bereitgestellt werden. Die Verwirrung beginnt hier: Seitenfunktionen werden auf derselben V8-Laufzeitumgebung wie Worker ausgeführt, haben dieselben Bindungen (D1, KV, R2, dauerhafte Objekte) und dieselben CPU- und Speichergrenzen. Der Unterschied zwischen Seitenfunktionen und reinen Workern ist nicht technischer Natur, sondern betrieblicher Natur.

Das Konto, das alles verändert

Im Workers-Tarif (5 US-Dollar/Monat) sind 10 Millionen Anfragen enthalten und Sie zahlen darüber hinaus 0,30 US-Dollar pro Million. Jede von der Laufzeit verarbeitete HTTP-Anfrage zählt.

In Pages kosten Anfragen nach statischen Assets nichts pro Anfrage – sie werden vom CDN von Cloudflare bedient, ohne die Workers-Laufzeit auszulösen. Sie zahlen für die Builds (20 $/Monat für den Pro-Plan, mit bis zu 5.000 Builds/Monat und 5 gleichzeitigen Builds). Anfragen für Seitenfunktionen verbrauchen das gleiche Budget wie Worker.

Auf einen realen Fall übertragen: eine Website mit 100 Millionen monatlichen Anfragen, 90 % für statische Assets (JS-Bundles, Bilder, HTML-Seiten) und 10 % für API-Routen. Auf Pages kosten die 90 Millionen statischen Anfragen 0 US-Dollar. Die 10 Millionen Funktionsaufrufe sind Teil der kostenlosen Funktionen im Pro-Plan. In der entsprechenden Architektur mit reinen Workern, die dieselben Assets über fetch() bedienen, im Vergleich zu einem R2-Bucket würden Sie 27 $/Monat allein für die Differenz zahlen (0,30 $ × 90 Millionen Anfragen über den enthaltenen 10 Millionen).

Dieser Unterschied ist struktureller Natur und verschwindet mit zunehmender Skala nicht – er verschlimmert sich.

Wo Arbeitnehmer einen echten Vorteil haben

Bestimmte Grundelemente gibt es nur in Workers. Cron-Trigger – die Möglichkeit, Code zu einem geplanten Zeitpunkt auszuführen – gibt es in Pages nicht. Wenn Sie einen Job benötigen, der stündlich ausgeführt wird, um Daten zu synchronisieren, eine Warteschlange zu verarbeiten oder abgelaufene Datensätze zu bereinigen, ist dies Workers. Es gibt kein Äquivalent in Pages.

Workers unterstützt auch Queues-Consumer (Nachrichten von Cloudflare-Warteschlangen asynchron verarbeiten), Email Workers (E-Mails empfangen und verarbeiten) und Workers for Platforms (Versand für vom Benutzer bereitgestellte Skripte, nützlich für SaaS mit mehreren Mandanten). Diese Nicht-HTTP-Trigger gibt es nur im Workers-Modell.

Langlebige Objekte funktionieren in beiden Fällen, aber die komplexe Koordination zwischen mehreren Instanzen – zum Beispiel einem verteilten zustandsbehafteten WebSocket-Server – ist in Workers tendenziell sauberer, wo Sie die volle Kontrolle über Bereitstellung und Routing haben.

Das eigentliche Overlay

Seitenfunktionen und Worker teilen sich genau die gleiche Laufzeit. Die Limits sind identisch: 128 MB Arbeitsspeicher (hartes Limit), 10 MB komprimiertes Skript im kostenpflichtigen Plan, 1.000 Unteranfragen pro Aufruf im kostenpflichtigen Plan, 30 Sekunden CPU pro Anfrage. Die verfügbaren Bindungen sind dieselben: D1, KV, R2, dauerhafte Objekte, KI, Servicebindungen zum Aufrufen anderer Worker.

Dies bedeutet, dass eine Mittelklasse-API vollständig auf Pages-Funktionen aufgebaut werden kann, ohne Einbußen bei der Laufzeitfähigkeit hinnehmen zu müssen. Die Frage lautet nicht „welches mehr Rechenleistung hat“, sondern „welches Bereitstellungs- und Abrechnungsmodell für meine Arbeitslast am sinnvollsten ist“.

Die Entscheidungskriterien

Die Heuristik funktioniert folgendermaßen: Wenn Ihr Projekt über statische Assets verfügt, die durch Build generiert wurden (beliebiges Frontend-Framework, statischer Site-Generator, SPA), ist Pages der natürliche Ausgangspunkt. Sie erhalten ein globales CDN für Assets ohne Kosten pro Anfrage, automatische Vorschaubereitstellungen pro Zweigstelle und eine integrierte Build-Pipeline. Die API-Routen sind in /functions und werden in derselben Workers-Laufzeit ausgeführt.

Wenn es sich bei dem Projekt um ein Compute-First-Projekt handelt – ohne nennenswerte statische Assets oder mit Nicht-HTTP-Triggern wie Cron, Warteschlangen und E-Mail – ist Workers die direkte Wahl. Das Bereitstellungsmodell über wrangler.toml ist expliziter, im Code versionierbar und lässt sich besser in benutzerdefinierte CI/CD-Workflows integrieren.

Die meisten Projekte leben nicht nur in einem Extrem. Ein typisches SaaS verfügt über ein Frontend (Pages, mit kostenlosem CDN), eine API (Pages-Funktionen, gleiche Codebasis, gleiche Bereitstellung) und eine Reihe von Hintergrundjobs (separate Worker, mit Cron-Triggern). Diese Hintergrund-Worker stellen über Service Bindings eine Verbindung zum Pages-Projekt her – direkte Anrufe zwischen Workern, ohne über das öffentliche Internet zu gehen.

Was die Dokumentation nicht erklärt

Cloudflare dokumentiert Worker und Pages als separate Produkte mit separaten Seiten, wodurch ein wichtiges Detail verdeckt wird: Ein Pages-Projekt kann externe Worker über Servicebindungen aufrufen, und externe Worker können Assets aus einem Pages-Projekt bereitstellen. Es sind keine Silos. Es sind Teile, die zusammenpassen.

Der häufigste Fehler besteht darin, in Workers erneut zu implementieren, was Pages kostenlos macht – statische Assets bereitzustellen –, weil jemand zuerst über Workers gelesen hat und dachte, es sei „fortgeschrittener“. Workers ist nicht weiter fortgeschritten als Pages. Es ist ein anderes Werkzeug für eine andere Ebene des Problems.