Vor dem Worker steht jetzt ein Vorwärmer. Nicht aus Höflichkeit, sondern weil im Maschinenraum wieder jemand gezählt hat, wie oft dieselbe Anfrage an derselben Kurbel zieht. Links kommen die Zettel rein, rechts kommt die Antwort raus, und der Worker dahinter darf zum ersten Mal seit langem so tun, als hätte er eine Mittagspause.
Cloudflare hat im eigenen Blog Workers Cache angekündigt: eine tiered Cache-Schicht direkt vor dem Worker. Aktiviert wird sie laut Cloudflare mit einem Wrangler-Konfigurationsblock, gesteuert weiter über bekannte HTTP-Header wie Cache-Control, inklusive stale-while-revalidate, Vary und Tag-Purge. Wenn eine frische Antwort im Cache liegt, läuft der Worker gar nicht erst los — und es fällt auch keine CPU-Zeit dafür an.
Die Kurbel dreht nur noch bei Bedarf
Das klingt klein. Ein Cache vor Code, na wunderbar, bitte neben die anderen Blechschubladen stellen. Aber für Worker ist die Stelle interessant: Bisher war der Worker oft der Ursprung selbst, also der kleine Mann an der Kurbel, der aus jeder Anfrage etwas zusammenpresst. Mit Workers Cache bekommt er einen Tresen davor. Der Tresen beantwortet, was schon sauber warmliegt. Der Kurbelmann wird nur geweckt, wenn wirklich etwas fehlt.
Cloudflare beschreibt das ausdrücklich als Cache, der dem Worker folgt: auf Custom Domains, auf workers.dev, hinter Service Bindings, in Previews und in Workers-for-Platforms-Tenants. Also nicht die alte Nummer „erst Zonenregel suchen, dann Schalter merken, dann beten, dass Preview und Produktion nicht verschiedene Dialekte sprechen“. Der Code bleibt die Bedienfläche. Der Cache wird zum Anhänger, der nicht dauernd den Führerschein sehen will.
Stale heißt hier nicht gammelig
Der schönste rostige Begriff in dieser Sache ist stale-while-revalidate. Abgelaufen, aber noch brauchbar. Wie ein Formular von 1998, nur schneller. Der Cache darf eine ältere Antwort sofort ausgeben, während im Hintergrund nachgeladen wird. Für Besucher fühlt sich das statisch an, für Betreiber bleibt es dynamisch genug, und irgendwo im Rack atmet ein Prozess leiser.
Cloudflare nennt als Beispiel gerenderte Seiten: Wenn die Seite frisch im Cache liegt, wird sie wie statisch ausgeliefert. Wenn sie abläuft, triggert die nächste Anfrage eine Neuerzeugung — mit stale-while-revalidate muss diese Anfrage aber nicht auf die Kurbel warten. Das ist kein neues Zauberwort, eher die alte HTTP-Werkzeugkiste mit einem vernünftigen Griff dran.
Tag-Purge: der kleine Schredder rechts außen
Interessant ist auch der Purge-Teil. Antworten können mit Cache-Tags versehen und später gezielt geleert werden. In der Werkstatt heißt das: Nicht die ganze Halle fluten, wenn ein Produktzettel geändert wurde. Nur die passenden farbigen Marken in den Schredder werfen, einmal knirschen lassen, weiterarbeiten.
Natürlich bleibt Cache-Infrastruktur eine Maschine mit Zähnen. Wer falsche Header setzt, falsche Varianten mit Vary vergisst oder personenbezogene Antworten versehentlich warmhält, baut keinen Vorwärmer, sondern einen Aktenkopierer ohne Aufsicht. Cloudflares Ankündigung macht die Bedienung kleiner, nicht die Verantwortung. Das ist ein Unterschied, der in Presswerken gerne unter Schrauben fällt.
Für die Blechpresse ist das die eigentliche Meldung: Edge-Code wird nicht nur schneller, er bekommt mehr normale Web-Mechanik vor die Nase. HTTP-Header, Cache-Tags, alte Stale-Tricks, aber näher an der Ausführungsmaschine. Der Worker bleibt da. Nur muss er nicht mehr jeden Zettel persönlich mit Öl unterschreiben. Und irgendwo quietscht eine Kurbel beleidigt, weil sie plötzlich weniger wichtig ist.
Quelle
Cloudflare Blog: „Your Worker can now have its own cache in front of it“ (6. Juli 2026).