Die Plattformdokumentation beschreibt in der Regel jedes Produkt isoliert und aus dem bestmöglichen Blickwinkel. Dadurch entsteht eine Lesart, bei der „Workers“ mächtiger erscheint als „Pages“ und „Pages“ einfacher zu sein scheint als „Workers“. Keine der beiden Lesarten ist korrekt. Sie verfügen in jeder Richtung über wirklich einzigartige Fähigkeiten – und einen großen Überschneidungsbereich, in dem der Unterschied nur im Bereitstellungsmodell besteht.
Was nur Arbeiter haben
Cron-Trigger sind das relevanteste Grundelement, das in Pages nicht vorhanden ist. In wrangler.toml:
[triggers] crons = ["0 3 * * *", "*/15 * * * *"]
Dabei werden zwei Crons aufgezeichnet: einer jeden Tag um 3 Uhr morgens, ein weiterer alle 15 Minuten. Der entsprechende Handler ist Methode scheduled des vom Worker exportierten Objekts. Pages verfügt nicht über dieses Grundelement. Es handelt sich nicht um eine Laufzeitbeschränkung, sondern um eine Produktentscheidung. Wenn Sie eine regelmäßige Ausführung benötigen, ist es ein freiberuflicher Mitarbeiter.
Warteschlangenkonsumenten funktionieren auf ähnliche Weise. Mit Cloudflare Queues können Sie Nachrichten in eine Warteschlange stellen und sie asynchron verarbeiten. Der Verbraucher – der Worker, der aus der Warteschlange liest – ist bei wrangler.toml mit [[queues.consumers]] konfiguriert. Seitenfunktionen können keine Warteschlangenkonsumenten sein; kann Nachrichten nur per Bindung in Warteschlangen veröffentlichen.
E-Mail-Mitarbeiter erhalten E-Mails direkt. Sie konfigurieren eine E-Mail-Route in Cloudflare so, dass sie auf einen Worker verweist, und der Worker empfängt die E-Mail als Objekt mit Absender, Empfänger, Headern und Text. Dadurch können Sie Bounces verarbeiten, Rechnungsbelege analysieren oder E-Mails an verschiedene Warteschlangen weiterleiten – und das alles ohne Ihren eigenen E-Mail-Server. Pages unterstützt diesen Auslöser nicht.
Workers for Platforms ist der Mandantenfähigkeitsmechanismus, bei dem SaaS-Benutzer ihre eigenen Worker innerhalb des Kontos des Betreibers bereitstellen können. Der Betreiber nutzt einen Dispatch Worker, der Anfragen entgegennimmt und an das richtige Mandantenskript weiterleitet. Es handelt sich um ein Infrastrukturprimitiv für Plattformen, die beliebigen Benutzercode mit garantierter Isolation ausführen müssen. Exklusiv für Arbeitnehmer.
TCP-Sockets (in der Betaversion) ermöglichen direkte TCP-Verbindungen von einem Worker – nützlich für die Verbindung zu Datenbanken, die keine HTTP-API haben, wie z. B. PostgreSQL oder Redis ohne Upstash. Immer noch in der Entwicklung, aber ohne Äquivalent in Pages.
Alarme für langlebige Objekte verdienen eine gesonderte Erwähnung von langlebigen Objekten im Allgemeinen. DOs funktionieren in beiden Fällen, aber Alarme – Timer, die einen bestimmten DO zu einer definierten Zeit wecken – sind ein Planungsprimitiv, das Cron-Trigger für Fälle mit Status pro Entität ergänzt (z. B. Planen einer Erinnerung pro Benutzer). In beiden Laufzeiten verfügbar, aber die Orchestrierung startet normalerweise von einem Worker mit einem Cron- oder Warteschlangen-Trigger.
Was nur Pages hat
Das Hosten statischer Assets ohne Kosten pro Anfrage ist die am meisten unterschätzte Funktion von Pages und die teuerste bei der Replikation außerhalb von Pages. Wenn Sie ein Pages-Projekt bereitstellen, werden die statischen Dateien (HTML, CSS, JavaScript, Bilder, Schriftarten) über das globale CDN von Cloudflare verteilt. Anfragen für diese Assets durchlaufen nicht die Workers-Laufzeit – sie werden direkt vom CDN-Edge bedient, ohne Rechenlogik auszulösen, ohne als Aufruf zu zählen, ohne Kosten pro Anfrage, die über den Pages-Plan hinausgehen.
Der kostenlose Plan von Pages beinhaltet unbegrenzte CDN-Anfragen. Der kostenpflichtige Plan kostet 20 $/Monat und umfasst 5.000 Builds/Monat und bis zu 5 gleichzeitige Builds. Für eine Website mit Dutzenden Millionen monatlichen Seitenaufrufen ist dieser Mangel an Kosten pro statischer Anfrage ein erheblicher Abrechnungsvorteil gegenüber jeder Architektur, die auf reinen Workern basiert.
Der zweite Unterschied besteht in der Vorschau automatischer Bereitstellungen pro Zweig. Jeder Push zu einem Nicht-Hauptzweig generiert eine eindeutige URL im Format hash-branch.seuprojeto.pages.dev, wobei Assets und Funktionen zusammen ausgeführt werden. Keine zusätzliche Konfiguration, keine zu schreibenden CI-Skripte. Workers repliziert dies nicht nativ – Sie müssen den Ablauf der „Zweigstellenbereitstellung“ manuell in Ihrem CI einrichten.
Einzigartig ist auch die integrierte Build-Pipeline. Pages erkennt das Framework (Next.js, Astro, SvelteKit, Nuxt, Hugo, Gatsby), konfiguriert die Build-Standards und führt den Build-Prozess bei jedem Push in einer isolierten Umgebung aus. Für Worker liegt die Verantwortung für den Build bei Ihrem CI – was flexibler ist, aber mehr Konfigurationsaufwand erfordert.
Mit den Konventionen _redirects und _headers können Sie Weiterleitungen und HTTP-Header für statische Assets über reine Textdateien im Projektstamm ohne Code konfigurieren. Nützlich für URL-, HSTS-, Inhaltssicherheitsrichtlinien- und Cache-Header-Migrationen. Arbeiter können dasselbe mit Code implementieren, es ist jedoch ausführlicher.
Was haben die beiden gemeinsam?
Die V8-Laufzeit ist identisch. Die Grenzwerte sind die gleichen: 128 MB Arbeitsspeicher (hart), 10 MB komprimiertes Skript im kostenpflichtigen Plan, 30 Sekunden CPU pro Anfrage, 1.000 Unteranfragen pro Aufruf. Jeder Code, der in Workers ausgeführt wird, wird unverändert in Pages Functions ausgeführt.
Datenbindungen werden gemeinsam genutzt: D1 (SQLite am Rand), KV (verteilter Schlüsselwert), R2 (Objektspeicher), langlebige Objekte (koordinationskonsistenter Zustand), AI (Modellinferenz am Rand). Auf eine D1-Datenbank können sowohl Seitenfunktionen als auch ein autonomer Worker zugreifen, der auf demselben wrangler.toml konfiguriert ist, wobei die Bindung auf dieselbe Datenbank-ID verweist.
Dienstbindungen funktionieren in beide Richtungen: Eine Pages-Funktion kann einen eigenständigen Worker direkt über die interne Bindung aufrufen, ohne Latenz im öffentlichen Netzwerk. Ein Arbeiter kann einen anderen Arbeiter anrufen. Der Anruf ist ein normaler fetch()-Anruf gegen Bindung, wird jedoch intern über das Cloudflare-Netzwerk weitergeleitet.
Die Architektur, die jedes einzelne an der richtigen Stelle nutzt
Das Muster, das aus Projekten entsteht, die Worker und Pages korrekt verwenden, besteht aus drei Ebenen. Das erste ist das Pages-Projekt: Es stellt die SPA oder Build-generierte Website mit statischen Assets im CDN bereit, ohne dass pro Anfrage Kosten anfallen. Die API-Routen befinden sich in /functions/api/ – Seitenfunktionen, die zusammen mit dem Frontend lokalisiert sind, einschließlich der Zweigvorschau und greifen auf D1 und KV für Anwendungsdaten zu.
Die zweite Ebene sind Worker für asynchrone Jobs: eigenständige Skripte mit Cron-Triggern für die geplante Verarbeitung, Warteschlangenkonsumenten für asynchrone Arbeit, entkoppelt vom kritischen HTTP-Pfad, E-Mail-Worker für die E-Mail-Verarbeitung. Diese Worker greifen auf dieselben Datenbindungen wie das Pages-Projekt zu – dieselbe D1-Datenbank, denselben KV-Namespace.
Die dritte Ebene ist die Kommunikation zwischen ihnen über Service Bindings. Eine Pages-Funktion, die eine umfangreiche Verarbeitung erfordert, ruft den spezialisierten Worker direkt auf, ohne externes HTTP. Der Cron-Worker, der eine Benachrichtigung auslösen muss, kann die sendende Seitenfunktion über Service Binding aufrufen.
Diese Architektur ist nicht theoretisch. Das passiert, wenn Sie jedes Grundelement dort verwenden, wo es das Problem mit geringeren Betriebskosten löst: Pages kostenloses CDN für Assets, gleiche Laufzeit für die am selben Ort befindliche API, eigenständige Worker für die Trigger, die Pages nicht unterstützt.
Die Entscheidungskarte
Die Frage, die die Entscheidung organisiert, ist: Was löst diesen Code aus? Wenn es sich um eine HTTP-Anfrage handelt und der Code mit einem Frontend zusammenlebt, funktioniert Pages. Wenn es sich um eine HTTP-Anfrage handelt, das Projekt jedoch kein Frontend – reinen API-Dienst – Worker mit Konfiguration in wrangler.toml hat. Wenn es um etwas anderes als HTTP geht – geplante Zeit, Warteschlangennachricht, eingehende E-Mail – haben Mitarbeiter keine Alternative.
Beide Seiten des Tisches verfügen über Fähigkeiten, die die andere Seite nicht ohne zusätzliche Kosten oder Komplexität replizieren kann. Eine Entscheidung, die dies ignoriert – nur Workers zu verwenden, weil Sie es für „ernsthafter“ halten, oder nur Pages, weil Sie es für einfacher halten – stößt an eine Grenze, die eine Umgestaltung früher als nötig erfordert.
Lesen Sie auch
- Cloudflare Workers vs. Pages: Der Unterschied, der wichtig ist, bevor Sie sich entscheiden
- Migration von Pages zu Workers: wann es sinnvoll ist und die tatsächlichen Kosten der Änderung
- Worker und Seiten: Bereitstellung, Routing und was jedes Modell verbirgt
- Seitenfunktionen: wann anstelle von reinen Arbeitern zu verwenden
- KV für Ratenbegrenzung, Feature-Flags und verteilte Konfiguration: wo es funktioniert und wo es kaputt geht
- Cloudflare KV: Was bedeutet global verteilt, wenn Sie schreiben müssen