Kostenlose Webflow-Bildoptimierung mit Cloudflare (2026): unser Open-Source-O2O-Worker

AKTUALISIERT (2. Oktober 2026): Dieser Beitrag wurde für Version 6 unseres Workers komplett neu geschrieben, und der ist jetzt kostenlos, Open Source und auf GitHub. Wenn du der Januar-Version dieser Anleitung gefolgt bist (der mit den /cdn-cgi/image/-Links, einer DOMAIN-Variable und einem CodePen, den du ins Dashboard kopiert hast), spring runter zum Abschnitt "Upgrade vom alten Worker". Alles andere hier unten ist neu.

Wir versuchen jetzt seit ungefähr vier Jahren, Webflow und Cloudflare dazu zu bringen, sich zu vertragen. Erst war es ein Hack mit den SSL-Einstellungen und der Cassette-App zum Cachen und Optimieren von Bildern. Dann hat Cloudflare die Apps abgeschafft, und wir haben einen eigenen Worker zum Proxyen und Cachen von Webflow-Bildern geschrieben. Dann ist Webflow mit seinem Hosting zu Cloudflare umgezogen, Orange-to-Orange (O2O) hat endlich richtig funktioniert, und im Januar haben wir die erste Version dieser Anleitung veröffentlicht, mit einem größeren, besseren Worker, der auch CSS, JS und Schriften übernommen hat.

Und jetzt, ganz ehrlich, sind wir ein bisschen übers Ziel hinausgeschossen. Der Worker wurde von Grund auf neu gebaut, er läuft seit Ende September auf unserer eigenen Site und seit dem 1. Oktober auf einer zweiten Site, er wurde mit fünf echten Seiten von vier verschiedenen Webflow-Sites getestet, und wir haben das Ganze kostenlos auf GitHub gestellt, mit einem Deploy-Button. Kein Skript mehr aus einem CodePen kopieren. Du klickst einen Button, fügst ein Secret ein, ergänzt eine Zeile, und fertig.

Wir nennen ihn den Milk Moon Webflow Optimizer. Hier erfährst du, was er macht, warum er sich an die Regeln von Webflow hält, wie das Caching funktioniert, was er einspart, jede Einstellung, das komplette Setup vom DNS bis zum fertigen Ergebnis und all das Zeug, das schiefgehen kann. Der Beitrag ist lang, also hol dir einen Kaffee.

Die Kurzfassung

Der Milk Moon Webflow Optimizer ist ein Cloudflare Worker, der vor deiner Webflow-Site sitzt (im Grunde ein Webflow-Reverse-Proxy für deine Dateien). Während jede Seite durchströmt, tauscht er jede Adresse von Webflow-Bildern, Stylesheets, Skripten und Schriften gegen eine Adresse auf deiner eigenen Domain aus. Wenn der Browser diese Dateien anfordert, holt der Worker sie einmal von Webflow, schrumpft die Bilder auf AVIF oder WebP (je nachdem, was der Browser des jeweiligen Besuchers öffnen kann) und legt alles im Cache von Cloudflare ab, nah an deinen Besuchern, für bis zu ein Jahr. Alle danach bekommen die gecachte Kopie.

Was du bekommst:

• Jedes PNG-, JPG-, GIF- und WebP-Bild wird spontan in AVIF oder WebP umgewandelt. Niemand muss in Webflow irgendetwas neu exportieren.
• Bilder, CSS, JS und Schriften werden von deiner Domain ausgeliefert und am Edge von Cloudflare gecached.
• Viel weniger Daten, die aus Webflow herausgehen, und genau dafür stellt Webflow dir eine Rechnung.
• Seiten, die sich trotzdem in dem Moment aktualisieren, in dem du auf Publish klickst.
• Social-Vorschaubilder, die immer funktionieren (für LinkedIn, Facebook, WhatsApp und X in JPEG umgewandelt), plus das og:url-Tag, das Webflow nie hinzufügt.
• Optional Bilder, die in der Größe heruntergeladen werden, in der sie tatsächlich angezeigt werden, nicht in der Größe, die Webflow geraten hat.
• Deine Site sieht genau gleich aus. Gleiches Design, gleiche Interactions, gleicher Inhalt.

Auf unserer Startseite wiegen die 38 wichtigsten Bilddateien heute 8.762 KB direkt von Webflow und 1.755 KB über den Worker. Das sind 80 % weniger, und kein einziges Bild ist größer herausgekommen als das Original. Der schlimmste Übeltäter, ein 2,7 MB großer PNG-Screenshot eines Projekts, kommt jetzt als 198-KB-WebP an. Gleiches Bild.

Warum der Aufwand? Das Problem mit den Dateiservern von Webflow

Webflow ist brillant darin, Sites zu bauen und zu hosten, sonst wären wir kein Webflow-Studio. Aber die Art, wie es deine Dateien ausliefert, hat drei Haken, und alle kosten dich Geld oder Tempo.

1. Deine Bilder gehen so raus, wie du sie hochgeladen hast. Webflow erstellt zwar ein paar kleinere Kopien jedes Bildes für verschiedene Bildschirmgrößen (die -p-500-, -p-800-Dateien, die du wahrscheinlich schon gesehen hast), und im Assets-Panel gibt es ein Compress-Tool, das Bilder in AVIF oder WebP umwandelt. Aber das ist Handarbeit, es ersetzt deine Originale, und alles, was du nicht umgewandelt hast, geht immer noch genau so raus, wie du es hochgeladen hast. Ein PNG-Screenshot, den du hochgeladen hast, bleibt ein PNG, und er geht an jedes Handy als PNG. Moderne Formate wie AVIF und WebP bringen dasselbe Bild auf einen Bruchteil der Größe, ohne einen Unterschied, den du je sehen würdest.

2. Webflow berechnet Bandbreite. Jeder Site-Plan hat ein monatliches Bandbreitenkontingent, und laut Webflows eigener Definition ist die Gesamtbandbreite "jedes Byte, das Webflows CDN für deine Site ausliefert, einschließlich HTML, CSS, JavaScript und Assets". Bots zählen. 404-Fehler zählen. Liegst du zwei Monate hintereinander drüber, wird dein Plan automatisch eine Stufe hochgesetzt. Schwere Bilder und wiederholte Downloads sind genau das, was diese Zahl in die Höhe treibt.

3. Deine Dateien liegen nicht auf deiner Domain. Selbst mit aktiviertem O2O liegen deine Bilder, CSS und Schriften auf cdn.prod.website-files.com (und ein paar älteren Webflow-Hosts). Das ist nicht deine Domain, also kann deine Cloudflare-Zone sie nicht anfassen. Keine Caching-Regeln von Cloudflare, keine Bildoptimierung, nichts. Die orange Wolke deckt nur deine Seiten ab.

Der Worker behebt alle drei, und das, ohne irgendetwas an deinem Webflow-Projekt zu ändern.

Ist das erlaubt? Webflow, O2O und die Regeln

Kurze Antwort: ja, und über diesen Teil freuen wir uns am meisten, denn die alten Wege waren ehrlich gesagt nicht so toll. Die Cassette-App, die SSL-Tricks mit grauer Wolke, Asset-Subdomains, bei all dem haben wir gegen die Plattform gekämpft. Hier nicht.

So ist der Stand, in Webflows eigenen Worten:

• Das Help Center von Webflow sagt "O2O ist der unterstützte Weg, Cloudflare-Funktionen vor Webflow zu betreiben", und dass O2O mit jedem Cloudflare-Tarif verfügbar ist, auch mit Free.
• Cloudflares eigene Kompatibilitätstabelle für O2O-Produkte führt Workers als unterstützt, mit einer vernünftigen Warnung: Ein Worker auf deinem O2O-Host kann deine Besucher beeinträchtigen, wenn er sich danebenbenimmt. Genau deshalb hat unserer die Sicherheitssperren, über die du weiter unten liest. Dieselbe Tabelle sagt auch, dass von Caching auf deiner Seite generell abgeraten wird, vor allem bei HTML, weil Webflow deine Seiten bereits cached. Deshalb überlässt der Worker die Seiten standardmäßig Webflow und cached nur die Dateien von Webflow, die sich unter derselben Adresse nie ändern.
• Das Einzige, was das Help Center von Webflow ausdrücklich nennt, ist ein Reverse Proxy für deine *.webflow.io-Staging-Domain, der laut Webflow gegen die Nutzungsbedingungen verstößt. Die fassen wir nie an. Der Worker läuft nur auf deiner Custom Domain, und genau dort sollst du laut Webflow proxyen.
• Die Reverse-Proxy-Anleitung von Webflow verlangt außerdem, den vollständigen Pfad und Query-String durchzureichen und kein HTML-Rewriting zu betreiben, das interne Links verändert. Der Worker reicht jede Seitenanfrage unangetastet durch und schreibt immer nur die Adressen von Webflows eigenen Dateien um. Deine Links, deine Formulare, deine CMS-Seiten, deine Suche und Filter bleiben genau so, wie Webflow sie gebaut hat.

Zwei ehrliche Einschränkungen. Erstens: Das Support-Team von Webflow debuggt keinen Worker für dich, das sagen sie auch ganz offen ("Du verwaltest deinen Proxy"). Das ist fair, und es ist auch der Grund, warum das Abschalten eine einzeilige Änderung ist (mehr dazu beim Rollback). Zweitens: Wir behaupten nicht, dass Webflow unseren Worker abgesegnet hat. Was wir sagen: Er baut komplett auf dem Setup auf, das Webflow offiziell unterstützt, mit einer Cloudflare-Funktion, von der Cloudflare sagt, dass sie damit funktioniert. Keine Hacks.

So funktioniert's, ganz einfach erklärt

Stell dir Webflow als Fabrik vor, die alles für deinen Laden herstellt. Ohne den Worker wird jede Kundenbestellung direkt ab Fabrik verschickt, in der originalen sperrigen Verpackung, jedes einzelne Mal.

Der Worker ist ein Lagerleiter vor Ort. Wenn etwas zum ersten Mal bestellt wird, holt er es aus der Fabrik, packt es in die kleinste Schachtel um, in die es passt (je nachdem, was der Kunde öffnen kann, eine andere Schachtel), und stellt eine Kopie ins Regal. Danach werden die Kunden aus dem Regal vor Ort bedient. Das geht für sie schneller, und die Fabrik muss kaum noch etwas verschicken. Der Lagerleiter hält sich außerdem an strenge Regeln: Er bearbeitet nur Bestellungen, deren Etiketten er selbst geschrieben hat, er fasst bestimmte Lieferungen nie an (die Sicherheitschecks, die Analytics), und wenn irgendetwas schiefgeht, tritt er zur Seite und lässt die Bestellung direkt aus der Fabrik durchgehen, genau wie immer.

Hier das Ganze als richtiges Bild.

Schritt für Schritt

1. Ein Besucher fragt eine Seite an. Jemand öffnet deine Site. Dank O2O landet die Anfrage zuerst im nächstgelegenen Cloudflare-Rechenzentrum.
2. Der Worker holt die Seite von Webflow. Genau so, wie Webflow sie ausliefert.
3. Er prüft, ob es wirklich eine Webflow-Seite ist. Jede Webflow-Seite trägt eine kleine Markierung im <html>-Tag (data-wf-site). Keine Markierung (eine App, eine API, eine Login-Seite), und der Worker reicht die Antwort Byte für Byte weiter und macht sonst nichts.
4. Er schreibt die Dateiadressen um, während die Seite durchströmt. Jede Adresse von Webflow-Bildern, Stylesheets, Skripten und Schriften wird zu einer signierten Adresse auf deiner Domain. Das passiert, während die Seite noch ankommt, also fängt der Browser sofort an zu rendern. Der Worker hält nie erst die ganze Seite fest.
5. Der Browser fragt deine Domain nach diesen Dateien.
6. Der Worker prüft die Signatur, wandelt Bilder um und speichert alles. Bilder laufen durch den Bildkonverter von Cloudflare, und wenn die umgewandelte Version größer wäre als das Original (passiert bei bereits komprimierten Fotos), bekommst du stattdessen das Original.
7. Alle danach bekommen die gespeicherte Kopie. Aus dem Cache von Cloudflare, ohne dass der Worker überhaupt läuft und ohne dass Webflow nach irgendetwas gefragt wird.

Die signierten Links (und warum niemand deinen Worker missbrauchen kann)

Das ist der Teil, der Version 6 von allem unterscheidet, was wir vorher gemacht haben, also hab kurz Geduld mit mir.

Die Dateiserver von Webflow werden geteilt. Die Bilder aller Webflow-Kunden liegen auf demselben cdn.prod.website-files.com-Host, nur in verschiedenen Ordnern. Ein Worker, der sagt "Ich hole und optimiere alles vom Dateiserver von Webflow", bietet also, ohne es zu wollen, an, die Webflow-Dateien von irgendwem zu holen und zu optimieren, über deine Domain, auf deine Cloudflare-Rechnung. Unser alter Worker hatte genau dieses Loch, und wir haben es im September selbst gefunden (wir haben ihn noch am selben Tag auf die IDs unserer eigenen Site beschränkt und uns dann auf die Suche nach einer besseren Lösung gemacht).

Version 6 macht es richtig. Jede Adresse, die der Worker in deine Seite schreibt, bekommt eine kurze Signatur: 16 Zeichen, erzeugt mit HMAC-SHA256 und einem geheimen Schlüssel, den nur dein Worker kennt (der SIGNING_KEY, den du bei der Installation setzt). Wenn eine Anfrage für eine Datei reinkommt, berechnet der Worker die Signatur für genau diese Adresse neu. Passt sie, super. Passt sie nicht, weil jemand den Link erfunden, den Dateipfad geändert, ihn auf die Dateien einer anderen Site umgebogen oder sich einfach vertippt hat, gibt es ein 403, und nichts wird abgerufen. Nichts abgerufen heißt nichts, was Webflow oder der Bildkonverter dir in Rechnung stellen könnten.

Der schöne Nebeneffekt: Es gibt pro Site nichts zu konfigurieren. Keine Liste mit Webflow-Site-IDs, keine erlaubten Domains. Der Worker liefert nur aus, was er selbst geschrieben hat, Punkt.

So funktioniert das Caching

Beim Caching kommen das Tempo und die Bandbreitenersparnis her, und genau hier werden Leute auch nervös ("Was, wenn meine Besucher eine alte Version sehen?"). Deshalb hier ganz genau, was wo gespeichert wird und wie lange.

Dateien: ein Jahr, und das ist sicher

Bilder, CSS, JS und Schriften werden ein Jahr lang gespeichert, im Cache von Cloudflare und im Browser des Besuchers. Dass das sicher ist, liegt an einer Angewohnheit von Webflow, die uns massiv in die Karten spielt: Sobald sich eine Datei ändert, gibt Webflow ihr eine neue Adresse. Tausch ein Bild aus, und es bekommt eine neue ID im Dateinamen. Veröffentliche eine Style-Änderung, und deine CSS-Datei bekommt einen neuen Hash. Deine Seite zeigt einfach auf die neue Datei, also kann niemand jemals eine veraltete Kopie einer geänderten Datei bekommen. Kein Purge-Button, kein Webhook.

Der Cache, den wir nutzen, ist Workers Cache. Eine wiederholte Anfrage nach einer Datei beantwortet Cloudflare, ohne dass der Code des Workers überhaupt läuft. Du kannst es selbst sehen: Öffne die DevTools auf unserer Site, klick auf irgendein Bild oder Stylesheet, und du siehst cf-cache-status: HIT und cache-control: public, max-age=31536000, immutable. Die CSS-Datei, die ich gerade geprüft habe, lag schon seit zwei Tagen im Cache.

Bilder haben noch einen Trick drauf: eine Adresse, mehrere Versionen. Dieselbe Bild-URL wird einmal pro Browser-Sorte gespeichert (AVIF für die, die es öffnen können, WebP für den Rest, das Original für den einen oder anderen alten Browser), und jeder Browser bekommt die Kopie, nach der er gefragt hat (dafür ist der Vary: Accept-Header da). Darum musst du dich nicht kümmern.

Seiten: frisch bei jedem Publish

Bei Seiten sieht es anders aus, denn Seiten ändern sich, ohne ihre Adresse zu ändern. Webflow selbst sagt Browsern, Seiten 16 Tage lang zu behalten (max-age=1382400, schau mal in deine eigenen Response-Header). Deshalb sieht ein wiederkehrender Besucher nach einem Publish manchmal deine alte Startseite. Der Worker überschreibt das mit max-age=0, must-revalidate, sodass Browser bei jedem Besuch neu nachfragen.

Und standardmäßig speichert der Worker Seiten überhaupt nicht in deiner Zone. Webflow cached deine Seiten bereits in seinem eigenen Cloudflare-Setup und leert diesen Cache, wenn du veröffentlichst, und wenn du Webflow einfach machen lässt, ist ein Publish sofort sichtbar. Wenn du noch ein bisschen mehr herausquetschen willst, gibt es eine Einstellung (HTML_EDGE_TTL, siehe unten), um Seiten ein paar Minuten in deiner Zone zu behalten. Bei uns steht sie auf 10 Minuten, weil wir auf die harte Tour gelernt haben, dass Webflow den Cache deiner Zone beim Veröffentlichen nicht leert (wir haben zugesehen, wie ein Publish hinter einer 47 Minuten alten Kopie festhing). Zehn Minuten sind für uns ein guter Deal. Für die meisten Sites gilt: Lass es bei 0.

Was nie gecached wird

• Serverfehler von Webflow: werden nie gespeichert, also wird ein Ausfall bei Webflow nie "gemerkt".
• Fehlende Dateien (404): werden nur 60 Sekunden gespeichert, damit eine Datei, die kurz fehlt, nicht ein Jahr lang als fehlend festgenagelt wird.
• Eine fehlgeschlagene Bildumwandlung: Stattdessen wird das Originalbild ausgeliefert und eine Stunde gespeichert, damit die optimierte Version wieder übernimmt, sobald die Umwandlung funktioniert.
• Alles, was keine Webflow-Seite und keine signierte Datei ist: wird mit no-store durchgereicht.

Spart das wirklich Webflow-Bandbreite?

Ja. Webflow zählt jedes Byte, das sein CDN für deine Site ausliefert. Ohne den Worker zieht jeder Besucher jede Datei von Webflow. Mit dem Worker verlässt eine Datei Webflow ungefähr einmal pro Cloudflare-Standort, nämlich wenn jemand in der Nähe dieses Standorts sie zum ersten Mal braucht, und wird danach ein Jahr lang aus dem Cache von Cloudflare an alle anderen in der Gegend ausgeliefert.

An unserem ersten vollen Tag live wurden 92 % der Anfragen nach CSS, JS und Schriften und 79 % der Bildanfragen direkt aus dem Cache beantwortet, und das, während sich jeder Cloudflare-Standort auf der ganzen Welt noch zum ersten Mal füllte. Die Quote sollte steigen, sobald jeder Standort seine Kopie hat. Als Nächstes messen wir einen normalen Tag, und sobald wir die Zahl haben, aktualisieren wir das hier.

Zwei Dinge solltest du allerdings wissen. Deine Seiten kommen weiterhin von Webflow (genau das sorgt dafür, dass ein Publish sofort sichtbar ist), die Ersparnis liegt also bei den Dateien, und da steckt das Gewicht ohnehin. Und weil das Nutzungs-Dashboard von Webflow misst, was sein CDN verschickt, sinkt dort der Dateianteil deiner Bandbreite, nicht der Seitenanteil.

Bilder in der richtigen Größe (neu in 6.1)

Das hier ist subtil, und es ist mein Liebling, weil es etwas behebt, das niemand bemerkt, aber jeder bezahlt.

Webflow erstellt mehrere Größen von jedem Bild, das du hochlädst, und sagt dem Browser über das sizes-Attribut, wie breit das Bild angezeigt wird. Der Browser sucht sich dann eine Kopie aus. Das Problem: Webflow berechnet diese Zahl anhand der Designer-Canvas, nicht danach, wie das Bild wirklich auf der Seite landet, und sehr oft steht da 100vw ("dieses Bild füllt den ganzen Bildschirm"). Dein Blogbild, das eigentlich in einer 840 Pixel breiten Spalte sitzt, wird auf dem Desktop also als 3.200-Pixel-Kopie heruntergeladen. Der Browser hat Webflow vertraut. Die meisten dieser Bytes sieht nie jemand.

Schalte SIZES_AUTO ein, und der Worker ergänzt sizes="auto, …" bei Bildern mit Lazy Loading. Lazy-Bilder laden erst, wenn das Layout feststeht, also kann der Browser den echten Platz messen und die Kopie nehmen, die wirklich passt. Browser, die auto noch nicht verstehen, überspringen es einfach und nutzen wie bisher den Wert von Webflow, es kann also nichts kaputtgehen.

Gemessen in einem echten Browser auf unserer Site: Die Startseite ging auf dem Desktop von 670 KB Lazy-Bildern auf 404 KB runter, auf dem Handy von 376 KB auf 255 KB, und ein Blogbeitrag von 181 KB auf 95 KB. Null kaputte oder unscharfe Bilder. Witzig: Es funktioniert in beide Richtungen. Auf einer anderen Site, die wir getestet haben, hatte Webflow ein paar Bilder zu klein angesetzt, und die kommen jetzt schärfer (und etwas schwerer) heraus. Das ist der Browser, der es richtig macht, und genau darum geht's. Standardmäßig ist es aus, weil es ändert, welche Datei der Browser auswählt, aber bei uns ist es an.

Was er sonst noch alles macht

Die großen Themen sind Bilder und Caching, aber da drin steckt ein ganzer Haufen kleinerer Dinge, die wir eingebaut haben, nachdem wir auf echten Sites darüber gestolpert sind.

• Animierte GIFs bleiben animiert. GIFs werden immer nur zu WebP (das animiert sein kann), nie zu AVIF (das aus dem Konverter nicht animiert herauskommt).
• Nie größer als das Original. Ein großes, bereits komprimiertes Kamera-JPEG kann beim Neukodieren tatsächlich wachsen. Auf einer Site haben wir gesehen, wie ein 1,9-MB-Foto mit 3,6 MB zurückkam. Deshalb vergleicht der Worker bei einem Cache-Miss das umgewandelte Bild mit dem Original und schickt das kleinere. Diese eine Änderung hat eine Test-Site von 17 % schwerer auf 10 % leichter gebracht.
• Keine doppelten Downloads. Webflow sagt Browsern über einen Link-Header (den Cloudflare in Early Hints umwandelt), dass sie früh mit dem Abrufen deines CSS anfangen sollen. Der Worker richtet diese frühen Abrufe auf dieselbe Adresse aus, die auch die Seite nutzt, also wird nichts doppelt heruntergeladen. Font-Preloads lässt er absichtlich in Ruhe, weil Schriften aus dem CSS heraus geladen werden und ein Umschreiben genau den doppelten Download verursachen würde, den wir vermeiden wollen.
• Social-Vorschauen, die funktionieren. og:image und twitter:image gehen als komprimiertes JPEG raus (konfigurierbar), das einzige Format, das jede Plattform zuverlässig anzeigt.
• Das fehlende og:url. Webflow gibt es nie aus, obwohl es eines der vier grundlegenden Open-Graph-Tags ist. Der Worker ergänzt es mit der eigenen Canonical-Adresse der Seite, sodass Shares derselben Seite mit Tracking-Codes oder mit und ohne www als einer gezählt werden.
• Favicons, App-Icons, Video-Poster, Inline-Hintergrundbilder und <style>-Blöcke bekommen alle dieselbe Behandlung.
• Seltsame Dateinamen. Figma-Exporte lieben Leerzeichen, Klammern und Kommas, und Webflow speichert ein wörtliches %20 manchmal als %2520. Der Worker behält den Pfad Byte für Byte bei, also funktionieren all diese (zwischendurch taten sie das nicht, daher wissen wir es).
• Auch die 404-Seite wird optimiert. Die "Seite nicht gefunden"-Seite von Webflow ist eine vollständige Seite voller Webflow-Dateien und wird abgerechnet wie jede andere.
• Deine Sitemap bekommt das richtige Etikett. Webflow liefert /sitemap.xml mit einem RSS-Feed-Typ aus, der Worker korrigiert das zu application/xml.
• Fixes für die Strenge des Browsers. Manche älteren Webflow-Hosts schicken Skripte und Stylesheets mit einem generischen Dateityp, den ein Browser mit nosniff nicht ausführen will. Der Worker schickt den richtigen Typ. SVGs, die von deiner Domain ausgeliefert werden, bekommen eine abgeriegelte Sicherheitsrichtlinie, damit darin nichts ausgeführt werden kann.

Was er bewusst in Ruhe lässt

• Cloudflare Turnstile (der "Bist du ein Mensch?"-Check), Google Tag Manager, Google Analytics, Google Fonts, Webflow Optimize und Skripte von Marketplace-Apps. Die rotieren oder werden pro Besucher personalisiert, und sie ein Jahr lang zu cachen würde sie kaputtmachen. Das kennen wir schmerzhaft gut: Eine frühe Version hat Turnstile geproxyt und im Juli den Turnstile-Check auf unserem eigenen Scanner lahmgelegt.
• Die Runtime-Chunks von Webflow und die Skripte von Finsweet Attributes, die von ihrem eigenen Zuhause laden müssen, um ihre Geschwisterdateien zu finden.
• Video, das Range Requests braucht.
• Deine Links, Canonical-Tags, Preconnects und alles, was keine Webflow-Datei ist. CodePen, HubSpot, YouTube-Embeds laden alle ganz normal.

Das Sicherheitsnetz

Dieser Worker sitzt vor einer Live-Site, unsere eingeschlossen, also ist er darauf gebaut, langweilig zu scheitern. Hier jede Sperre und das, was sie verhindern soll:

• Er läuft nur auf der Route, die du ihm gibst. Richte ihn auf www.yoursite.com/* aus, und mehr sieht er nicht. (Unser Ausfall im Juli war eine Wildcard-Route, die bis zu unseren App-Subdomains reichte. Nutze nicht *.yoursite.com/*.)
• Er schreibt nur echte Webflow-Seiten um. Keine data-wf-site-Markierung, keine Änderungen, kein Caching. Selbst wenn die Route aus Versehen eine App erreicht, bliebe die App also unangetastet.
• Er liefert nur Links aus, die er signiert hat. Kein offenes Relay, niemand treibt deine Rechnung in die Höhe.
• Er holt nur von Webflows eigenen Dateiservern. Und vom jQuery-Host von Webflow nur /js/jquery….
• Eine falsche Einstellung heißt, er tritt zur Seite. SIGNING_KEY fehlt oder ist zu kurz? Jede Anfrage geht unangetastet durch, und der Fehler wird geloggt.
• Ein Fehler heißt: die Originalseite. Wenn etwas schiefgeht, bevor die Seite zu streamen beginnt, bekommst du die Antwort von Webflow, unangetastet. Der schlimmste Fall ist "so schnell wie pures Webflow", nie "die Site ist down".
• Er speichert keine kaputten Dateien. Eine Schrift, die als HTML-Fehlerseite zurückkommt, wird abgelehnt, statt ein Jahr lang als Schrift gecached zu werden.

Das komplette Setup, von Anfang bis Ende

Gut, hier ist das Setup. Zwei Teile: deine Domain mit O2O auf Cloudflare bringen (einmal pro Domain), dann den Worker installieren (einmal pro Site). Wenn du schon auf O2O bist, spring zu Teil 2.

Was du brauchst

• Einen kostenpflichtigen Webflow Site-Plan mit Custom Domain (O2O braucht einen).
• Eine Site auf dem Cloudflare-Hosting von Webflow. Sites, die nach dem 21. April 2025 erstellt wurden, sind das bereits, bei älteren Sites muss die DNS-Migration von Webflow erledigt sein (prüf das unter Workspace settings → Domain updates).
• Ein Cloudflare-Konto. Jeder Tarif, auch der Free-Tarif funktioniert. Unsere zweite Installation läuft auf Free.
• Ein GitHub-Konto, für den Deploy-Button (oder die Kommandozeile, wenn dir das lieber ist).

Teil 1, Schritt 1: Deine Domain zu Cloudflare hinzufügen

Klick im Cloudflare-Dashboard auf Onboard a domain, gib deine Root-Domain ein (yoursite.com) und folge den Schritten. Ändere dann bei deinem Registrar die Nameserver auf die zwei, die Cloudflare dir gibt. Es kann eine Weile dauern, bis das überall durch ist (Webflow sagt bis zu 48 Stunden, meistens geht es viel schneller). whatsmydns.net mit der NS-Option zeigt dir, wann es durch ist. Wenn das DNS trödelt, haben wir einen Beitrag zum Beschleunigen der DNS-Auflösung beim Veröffentlichen deiner Webflow-Site.

Teil 1, Schritt 2: DNS-Einträge mit aktivierter oranger Wolke

Das ist der O2O-Teil. Lege unter DNS → Records geproxyte CNAME-Einträge an:

• Type CNAME, Name @, Target cdn.webflow.com, Proxy status Proxied (orange Wolke AN)
• Type CNAME, Name www, Target cdn.webflow.com, Proxy status Proxied (orange Wolke AN)

Lösche alle alten A-Einträge, die auf 198.202.211.1 zeigen (oder auf die richtig alten Webflow-IPs oder auf proxy-ssl.webflow.com). Beides gleichzeitig geht nicht. Wenn du weitere Subdomains auf Webflow nutzt, füge für jede einen geproxyten CNAME hinzu. Und wenn deine Domain CAA-Einträge hat, stell sicher, dass sie Let's Encrypt und Google Trust Services erlauben, sonst werden deine Zertifikate nicht erneuert.

Teil 1, Schritt 3: SSL/TLS auf Full (strict)

Geh in Cloudflare zu SSL/TLS und stell den Verschlüsselungsmodus auf Full (strict). Bei allem anderen jagst du 525-Fehlern hinterher.

Teil 1, Schritt 4: In Webflow verbinden und veröffentlichen

Drüben in Webflow gehst du zu Site settings → Publishing → Production, verbindest deine Domain (Root und www), legst deine Standard-Domain fest und veröffentlichst.

Wahrscheinlich siehst du "Update needed" neben deiner Domain. Ignorier es. Sobald die orange Wolke an ist, kann der Check von Webflow deine DNS-Einträge nicht durch den Proxy sehen, und Webflows eigener Hilfeartikel sagt, dass das so zu erwarten ist. Wenn die Site lädt, ist alles gut. Bei manchen Sites hing die Warnung bei mir ewig herum, bei anderen ist sie verschwunden.

Um zu prüfen, ob O2O funktioniert: Die Site lädt, deine Einträge in Cloudflare zeigen die orange Wolke, und nach ein paar Minuten zeigt die Analytics deiner Domain im Cloudflare-Dashboard Traffic an. (Verlass dich nicht auf den cf-ray-Header, den hat inzwischen jede Webflow-Site, ob mit O2O oder ohne.) Gut, damit ist die Plattform erledigt. Jetzt kommt der spaßige Teil.

Teil 2, Schritt 5: Auf Deploy to Cloudflare klicken

Geh zu unserem Repo, github.com/J8kesVanEeden/milkmoon-webflow-optimizer, und klick im README auf den orangen Deploy to Cloudflare-Button. Das passiert dann, weil es beim ersten Mal nicht offensichtlich ist:

• Cloudflare bittet dich, dich anzumelden und GitHub zu verbinden.
• Es erstellt eine Kopie unseres Repositorys in deinem eigenen GitHub-Konto. Diese Kopie gehört dir: Deine Einstellungen liegen darin, und aus ihr baut Cloudflare.
• Es erstellt den Worker in deinem Cloudflare-Konto und verbindet ihn mit deiner Kopie, sodass Cloudflare jedes Mal automatisch neu deployt, wenn du eine Änderung darin committest (das ist Workers Builds).

Teil 2, Schritt 6: Einen SIGNING_KEY einfügen

Während des Deploys wirst du nach dem SIGNING_KEY gefragt. Das ist das Secret, mit dem dein Worker seine Links signiert. Füge einen zufälligen Wert mit mindestens 32 Zeichen ein. Auf einem Mac oder unter Linux liefert dir openssl rand -base64 36 im Terminal einen, oder du nimmst den Generator deines Passwortmanagers. Bewahr ihn sicher auf, aber eintippen musst du ihn nie wieder. Er wird als Cloudflare-Secret gespeichert, nicht in deinem Code, und ohne ihn deployt der Worker nicht.

Teil 2, Schritt 7: Ab auf deine Site damit

An diesem Punkt existiert der Worker, ist aber noch nicht auf deiner Site (mit Absicht, damit nichts überraschend passiert). Öffne in deiner Kopie des Repos auf GitHub die wrangler.jsonc, such den auskommentierten routes-Teil (drei Zeilen, die mit // anfangen), nimm bei allen dreien das // weg und trag deinen Webflow-Host ein:

"routes": [{ "pattern": "www.yoursite.com/*", "zone_name": "yoursite.com" }],

Committen. Cloudflare bemerkt das und deployt in etwa einer Minute neu. Nutze nur den Host, der deine Webflow-Site ausliefert. Nicht *.yoursite.com/*, vor allem nicht, wenn du Apps auf anderen Subdomains hast (vertrau uns). Und richte die Route hier in der Datei ein, nicht im Dashboard, denn die Datei ist das, was deployt wird, und sie überschreibt Änderungen im Dashboard.

Teil 2, Schritt 8: Die OWASP-Ausnahme (ab Pro-Tarif)

Wenn deine Zone im Pro-Tarif oder höher ist und du in den Managed Rules das OWASP Core Ruleset von Cloudflare nutzt, füge eine Ausnahme hinzu, sonst bekommen manche Besucher (und die Renderer von Google) statt deiner Bilder eine Challenge-Seite. Die OWASP-Regel 949110 sieht einen Webflow-Hostnamen im Dateipfad und wird misstrauisch. Es ist sicher, OWASP auf diesen Pfaden zu überspringen, weil jede Anfrage dort ohnehin schon über die Signatur des Workers geprüft wird. Das hat uns auf unserer eigenen Site erwischt: Rund 11 % der Dateianfragen bekamen eine Challenge, bis wir die Ausnahme hinzugefügt haben.

1. Cloudflare-Dashboard → deine Domain → Security rules → Create → Managed rules.
2. Gib ihr einen Namen wie Skip OWASP on Webflow Optimizer paths.
3. Bearbeite den Ausdruck und füge ein: starts_with(http.request.uri.path, "/_wf/") or starts_with(http.request.uri.path, "/_img/")
4. Dann: Skip specific rules from a Managed Ruleset → wähle das Cloudflare OWASP Core Ruleset → Select rules → alle auswählen → Next → Deploy.
5. Stell sicher, dass die Ausnahme über der Regel steht, die das OWASP-Ruleset deployt. Ausnahmen überspringen nur Regeln, die nach ihnen kommen.

Im Free-Tarif hast du das OWASP-Ruleset nicht, also kannst du diesen Schritt überspringen.

Teil 2, Schritt 9: Prüfen, ob es funktioniert

Führ das im Terminal aus (oder schau dir die Response-Header in den DevTools an):

curl -s -o /dev/null -D - https://www.yoursite.com/ | grep -i x-edge-worker

(Nimm genau diesen Befehl. Das kürzere curl -I schickt einen HEAD-Request, und den lässt der Worker absichtlich in Ruhe, also taucht der Header damit nie auf.)

Zurückkommen sollte x-edge-worker: webflow-o2o/6.1.0 (oder was auch immer die neueste Version ist). Dann:

• Sieh dir den Seitenquelltext an. Bildadressen sollten mit https://www.yoursite.com/_img/ beginnen und Stylesheets mit https://www.yoursite.com/_wf/.
• Öffne den Network-Tab in den DevTools, filtere nach Img und lade neu. Bilder sollten von deiner Domain kommen, mit content-type: image/avif oder image/webp.
• Lade noch einmal neu und prüfe die Header eines Bildes auf cf-cache-status: HIT.
• Prüfe, ob eine Seite mit Formular oder Turnstile noch funktioniert, und deine Social-Vorschauen in opengraph.xyz oder im Sharing Debugger von Facebook.

Der einfachste visuelle Check ist immer noch die DrFlare-Erweiterung für Chrome. Sie wurde eingestellt, ist aber als DrFlare Reloaded, hier erhältlich, zurückgekommen. Öffne sie über die DevTools, lade die Seite neu und fahr mit der Maus über Bilder, um Vorher und Nachher zu sehen. Denk daran, neu zu laden, sobald DrFlare offen ist.

Und das war die Installation. Kein "Enable Image Transformations"-Schalter, keine Liste erlaubter Origins, keine DOMAIN-Variable, kein Webhook zum Cache-Purgen. Die alte Anleitung hatte all das, und nichts davon wird mehr gebraucht: Der Worker wandelt Bilder selbst um, was Cloudflare auf jeder Zone erlaubt, auf der ein Worker läuft.

Lieber die Kommandozeile?

Dasselbe, von Hand: Klon das Repo, führ npm ci, npx wrangler login und npx wrangler secret put SIGNING_KEY aus (deinen Key einfügen), bearbeite routes in der wrangler.jsonc, dann npm run deploy. Du brauchst dafür Node. Die genauen Befehle stehen im README.

Jede Einstellung, erklärt

Alles ist optional außer dem Signing Key. Einstellungen gehören in den vars-Abschnitt der wrangler.jsonc in deiner Kopie des Repos (committen, und es wird neu deployt). Eine ungültige Zahl oder ein ungültiges Format fällt stillschweigend auf den Standard zurück, du kannst also nichts kaputtmachen, wenn du dich bei einer Qualitätseinstellung vertippst. Die zwei Ausnahmen sind der Signing Key und die Legacy-Einstellungen weiter unten: Wenn die falsch sind, tritt der Worker zur Seite (deine Site läuft weiter, nur eben ohne den Worker), bis du sie korrigierst.

• SIGNING_KEY (Pflicht, ein Secret, keine Var). Mindestens 32 zufällige Zeichen. Wenn du ihn später änderst, bekommt jede Datei eine neue Adresse, und der Cache muss einmal komplett neu befüllt werden. Keine Katastrophe, mach es nur nicht zum Spaß.
• IMAGE_QUALITY (Standard 85, 1 bis 100). Qualität für Bilder auf der Seite. 85 sieht großartig aus. Geh auf 75 runter, wenn du wirklich jedes Byte rausquetschen willst, für Fotografie würden wir nicht viel tiefer gehen.
• OG_FORMAT (Standard jpeg, png und webp sind auch erlaubt). Format für Social-Vorschaubilder. Lass es auf JPEG, manche Plattformen zeigen immer noch nichts anderes an.
• OG_QUALITY (Standard 80). Qualität für Social-Vorschaubilder.
• EDGE_TTL und BROWSER_TTL (Standard 31536000, ein Jahr, in Sekunden). Wie lange Dateien im Cache von Cloudflare und in Browsern bleiben. Ein Jahr ist sicher, weil Webflow geänderte Dateien umbenennt. Wir hatten noch nie einen Grund, das zu ändern.
• SIZES_AUTO (Standard false). Setz es auf "true" für die oben beschriebenen Bilder in der richtigen Größe. Wir haben es an, auf beiden unserer Installationen.
• HTML_EDGE_TTL (Standard 0, bis 86400). Sekunden, die Seiten in deiner Zone bleiben. Lass es auf 0, außer deine Route deckt nichts anderes ab als deine Webflow-Site, denn ein positiver Wert cached jede Antwort auf der Route, bevor der Worker prüfen kann, ob es eine Webflow-Seite ist. Wenn du es setzt, kann es bis zu dieser Zeitspanne dauern, bis ein Publish sichtbar ist (wir nutzen 600, also zehn Minuten).
• LEGACY_ROUTES, WEBFLOW_SITE_IDS, LEGACY_DOMAIN. Nur für Leute, die unseren alten Worker im Einsatz hatten. Siehe Upgrade, weiter unten. Neue Installationen brauchen sie nicht.

Ein paar Dinge in der wrangler.jsonc, die keine Einstellungen sind, über die du aber Bescheid wissen solltest:

• "cache": { "enabled": true, … } schaltet Workers Cache ein, und damit können wiederholte Anfragen den Worker komplett überspringen. Lass es an.
• "secrets": { "required": ["SIGNING_KEY"] } ist der Grund, warum ein Deploy ohne Key fehlschlägt, statt halb konfiguriert live zu gehen.
• "observability" behält Logs für 10 % der Anfragen, das reicht völlig, um ein Problem zu entdecken, und ist günstig.
• "workers_dev": false, weil dieser Worker nur auf deiner eigenen Domain Sinn ergibt.

Was es kostet

Der Worker ist kostenlos und MIT-lizenziert. Was du bezahlst, wenn überhaupt, ist Cloudflare:

• Workers-Anfragen. Jede Anfrage auf deiner Route zählt: Seiten und jede Bild-, CSS-, JS- und Schriftdatei, auch gecachte (ein Cache-Hit spart die Verarbeitungszeit des Workers, nicht die Zählung der Anfrage). Workers Free deckt 100.000 Anfragen pro Tag ab. Workers Paid kostet 5 $ im Monat mit 10 Millionen inklusive, danach 0,30 $ pro Million (Preise von Cloudflare). Grob überschlagen: Eine Seite mit 40 Dateien sind etwa 41 Anfragen, der kostenlose Tarif deckt also ungefähr 2.400 Seitenaufrufe pro Tag ab. Viele kleine Sites passen da locker rein, eine gut besuchte Site wird den 5-$-Tarif wollen. Gehst du bei Workers Free über 100.000, stellt Cloudflare dir nichts in Rechnung, sondern führt den Worker für den Rest des Tages einfach nicht mehr aus. Stell deine Route auf Fail Open (dein Worker → Settings → Domains & Routes), damit Besucher dann einfach pures Webflow bekommen statt einer Fehlerseite.
• Bildumwandlungen. Cloudflare schließt 5.000 einzigartige Transformationen pro Monat kostenlos ein. Eine einzigartige Transformation ist ein Bild mit einer Einstellung in einem Format pro Monat, und wiederholte Aufrufe sind kostenlos. Laut Cloudflare zählt ein Bild, das in verschiedenen Formaten ausgeliefert wird, nur einmal, aber wir fragen jedes Format einzeln an, also plan sicherheitshalber ein, dass ein Bild bis zu dreimal zählt (AVIF, WebP und das Original). Nach 5.000 schlagen neue Umwandlungen fehl, und der Worker liefert stillschweigend das Originalbild aus, bis der Monat zurückgesetzt wird, außer du bist auf Images Paid mit 0,50 $ pro 1.000 zusätzlichen (Preise). Zur Einordnung: Unsere Site, alle rund 600 Seiten, hat im ganzen September 732 verbraucht.

Vergleich das mit einer Hochstufung deines Webflow-Bandbreitentarifs, und die Entscheidung fällt nicht schwer.

Wird die Site dadurch schneller? Echte Zahlen

Mit Tempo-Versprechen sind wir vorsichtig, weil PageSpeed-Scores zwischen identischen Durchläufen um 10 bis 20 Punkte springen und vieles, was eine Site ausbremst (Skripte, Animationen, Tags von Drittanbietern), nichts mit Bildern zu tun hat. Also haben wir fair getestet: dieselben 8 Seiten auf unserer Live-Site (mit dem Worker) und auf Webflows eigener Staging-Kopie (ohne Worker), gleiches Tool, gleiche Geräte, direkt nebeneinander.

• Der Worker hat nie einen Score verschlechtert.
• Die PageSpeed-Warnungen zu Bildauslieferung und Seitengewicht waren mit dem Worker auf jeder Seite kleiner. Eine Projektseite wog mit ihm 3.196 KB und ohne ihn 4.195 KB.
• Seiten kommen genauso schnell an wie vorher: Der Median der Time to First Byte lag bei 95 ms auf Version 6 gegenüber 94 ms auf der Version davor (20 Seiten, je 5 Durchläufe). Das Umschreiben im Stream fügt wirklich keine Wartezeit hinzu.
• Bilder der Startseite, heute auf 6.1.0 gemessen: 38 Dateien, 8.762 KB direkt von Webflow, 1.755 KB über den Worker (80 % weniger), keine größer als das Original. AVIF für 20 davon, WebP für 17 und ein PNG, das schon so klein war, wie es nur geht.
• Die ersten 24 Stunden von Version 6 live: null Worker-Fehler, und sobald die OWASP-Ausnahme aus Schritt 8 drin war, 0,3 % der Dateianfragen abgelehnt (fast alles Bots, die nach Adressen fragten, die der Worker nie geschrieben hat, und die absichtlich abgewiesen wurden). Eine vollständige Prüfung jeder Seite und jeder Datei auf der Site hat bestanden (628 Seiten, 1.255 Dateien).

Und um ehrlich zu bleiben: Die großen Gewinne kommen von großen, unoptimierten Uploads wie PNG-Screenshots. Wenn deine Bilder schon kleine WebPs sind, ändern sich manche davon überhaupt nicht, weil Cloudflare das Original behält, wenn es schon das kleinste ist. Da funktioniert das System, es versagt nicht.

Unter der Haube (für Neugierige)

Dieser Teil ist für die Entwickler, und für den Moment, in dem etwas schiefgeht und du wissen willst, wo du nachschauen sollst. Hier ist jede Entscheidung, die der Worker für eine Anfrage trifft.

Ein paar Details, die man kennen sollte:

• Die Seite wird mit dem HTMLRewriter von Cloudflare umgeschrieben, der echte HTML-Attribute parst, während die Seite durchströmt (die Januar-Version hat acht Regex-Durchläufe über eine komplett gepufferte Seite gemacht, und so hat sie monatelang Social-Bilder und Favicons übersehen: Webflow schreibt content= vor property=, und der Regex hat nur in eine Richtung geschaut).
• Signierte Adressen sehen für Bilder so aus: /_img/img/<signature>/<webflow host>/<path>, und für alles andere so: /_wf/<signature>/<webflow host>/<path>. Es gibt nur zwei Bild-Presets, img und og. Ein Besucher kann nie eine andere Größe oder Qualität anfordern, und genau das hindert Leute daran, auf deinem Konto Umwandlungen zu erzeugen.
• Die Bildumwandlung passiert im Worker mit einem cf.image-Fetch, der anhand des Accept-Headers des Browsers AVIF oder WebP auswählt.
• Der Code ist reines JavaScript in zehn kleinen Dateien (das README hat eine Übersicht), mit 146 automatisierten Tests, die in derselben Runtime laufen, die Cloudflare nutzt, inklusive fünf echter Seiten von vier verschiedenen Webflow-Sites (und obendrauf noch einer kompletten zweiten Installation). Alles liegt auf GitHub, stöber ruhig mal rum.

Optional: Er kann sich selbst überwachen

Webflow kann sein Markup oder seine Datei-Hosts bei jedem Publish ändern, auf seiner Seite, ohne Vorwarnung. Die Sicherheitsnetze des Workers verhindern, dass deine Site kaputtgeht, aber sie sagen dir nicht, wenn eine Änderung deine Bilder still und leise unoptimiert lässt. Deshalb enthält deine Kopie des Repos einen optionalen Monitor, der auf GitHub Actions läuft: Stündlich prüft er, ob deine Seiten laden und deine Dateien über den Worker kommen, täglich prüft er jede Seite in deiner Sitemap und jede Datei darauf, und wenn etwas nicht stimmt, öffnet er ein GitHub-Issue (GitHub schickt dir eine E-Mail) und schließt es wieder, sobald alles in Ordnung ist. (GitHub startet geplante Läufe, wann immer es gerade dazu kommt, "stündlich" kann an einem vollen Tag also etwas großzügig ausfallen.) Er macht nichts, bis du ihn einrichtest, das README erklärt das Zwei-Minuten-Setup. An deiner Site ändert er nie etwas.

Upgrade vom alten Worker

Wenn du der Januar-Version dieses Beitrags gefolgt bist, gehst du so vor:

1. Installier Version 6 wie oben beschrieben (das ist ein neuer Worker über den Deploy-Button).
2. Sorg dafür, dass deine alten Links weiter funktionieren. Google Images, alte Social-Shares und gecachte Seiten fragen noch eine Weile nach den alten Adressen /img-original/, /img-cache/, /asset-cache/ und /cdn-cgi/image/. Setz LEGACY_ROUTES auf "true", WEBFLOW_SITE_IDS auf deine Webflow-Site- und CMS-IDs (kommagetrennt, die 24-stelligen IDs in deinen Webflow-Dateiadressen) und LEGACY_DOMAIN auf genau den Host, auf dem deine Site läuft, etwa www.yoursite.com (nicht die nackte Domain, wenn du auf www bist). Setz alle drei zusammen: Wenn LEGACY_ROUTES an ist und die IDs oder die Domain fehlen, tritt der Worker komplett zur Seite, bis du das behebst, und der x-edge-worker-Header verschwindet. Sind alle drei gesetzt, beantwortet der neue Worker auch die alten Adressformen, beschränkt auf deine eigenen Dateien.
3. Zieh die Route um. Entferne die Route vom alten Worker und füge sie beim neuen hinzu. Danach kannst du den alten Worker löschen.
4. Lass Image Transformations vorerst an. Die alten /cdn-cgi/image/-Links liefert Cloudflare direkt aus, nicht der Worker, also lass Transformations (und deine erlaubten Origins) an, solange noch alter Traffic reintröpfelt, und riegle diesen Endpunkt mit einer WAF-Regel ab, damit ihn sonst niemand nutzen kann. Sobald deine Logs zeigen, dass die alten Links ausgestorben sind, kannst du alles abschalten.

Version 6 selbst später zu aktualisieren ist einfach: Zieh unsere neueste Version in deine Kopie des Repos (unser Repo als Remote hinzufügen und reinmergen) und committe, und Cloudflare deployt neu. Deine Einstellungen und dein Secret bleiben, wo sie sind. Nimm für Updates nicht den Deploy-Button, der macht eine brandneue Kopie und einen brandneuen Worker, statt deinen zu aktualisieren. Der x-edge-worker-Header sagt dir, welche Version du fährst.

Fehlerbehebung

Nichts hat sich geändert, Bildadressen zeigen immer noch auf Webflow

• Prüfe, ob die Route in der wrangler.jsonc nicht mehr auskommentiert ist und genau zu deinem Host passt (www.yoursite.com/*, nicht die Apex-Domain, wenn deine Site auf www liegt).
• Prüfe, ob das Deploy wirklich gelaufen ist: Cloudflare-Dashboard → dein Worker → Deployments (oder der Builds-Tab).
• Prüfe den x-edge-worker-Header. Kein Header heißt, der Worker ist nicht auf dieser Route, oder der SIGNING_KEY fehlt (dann reicht er alles unangetastet durch und loggt, warum).
• Hard Refresh (Cmd/Ctrl + Shift + R). Dein Browser hat vielleicht noch eine Kopie der Seite von vorher.

Manche Bilder zeigen eine Challenge oder ein 403

• Eine Challenge-Seite, oder Bilder, die nur bei manchen Besuchern nicht laden: Das ist das OWASP-Ruleset. Füge die Ausnahme aus Schritt 8 hinzu und stell sicher, dass sie über der OWASP-Regel steht.
• Ein schlichtes 403 "Bad or missing signature": Der Link wurde nicht von deinem Worker geschrieben. Meistens eine alte Kopie einer Seite von vor der Änderung deines SIGNING_KEY, oder jemand (oder ein Bot), der an einem Link herumgebastelt hat. Lade die Seite neu, um frische Links zu bekommen.

Bilder sind nicht AVIF oder WebP

• Prüfe, ob die Adresse /_img/ enthält. SVGs und Bilder, die du als AVIF hochgeladen hast, werden absichtlich so ausgeliefert, wie sie sind (Cloudflare kann AVIF nicht umwandeln, und SVGs brauchen es nicht). Lade JPG oder PNG in Webflow hoch und lass den Worker die Umwandlung machen, Webflow erstellt für AVIF-Uploads nicht einmal responsive Größen.
• Wenn du deine 5.000 kostenlosen Umwandlungen für den Monat aufgebraucht hast, kommen neue Bilder als Originale durch, bis der Monat zurückgesetzt wird. Das Cloudflare-Dashboard (Images → Transformations) zeigt dir deinen Zählerstand.

Mein Publish taucht nicht auf

• Mit dem Standardwert von 0 für HTML_EDGE_TTL sollte es sofort da sein. Wenn du einen höheren Wert gesetzt hast, warte so lange oder purge die Seite in Cloudflare (Caching → Configuration → Custom Purge).
• Probier es in einem privaten Fenster, um deinen eigenen Browser auszuschließen.

Social-Vorschauen sehen falsch aus

• Jag die Seite durch den Sharing Debugger von Facebook oder durch opengraph.xyz. Das og:image sollte eine /_img/og/-Adresse auf deiner Domain sein und als JPEG zurückkommen. Plattformen cachen Vorschauen eine Weile, also nutze im Debugger "Scrape Again".
• Social-Bilder, die du als AVIF hochgeladen hast, bleiben absichtlich auf der Adresse von Webflow, weil Social-Scraper schlecht mit AVIF umgehen. Lade für dein Open-Graph-Bild ein JPG hoch.

Webflow zeigt "Update needed" bei meiner Domain

Bei O2O zu erwarten. Webflow kann dein DNS nicht durch die orange Wolke sehen. Wenn die Site lädt, ignorier es.

525 Handshake Error

Das ist SSL, nicht der Worker. Stell SSL/TLS auf Full (strict). Wenn deine Zone Zone Hold nutzt, sagt die Doku von Webflow, dass du es aufheben sollst, solange das Zertifikat ausgestellt wird.

Grenzen (nichts ist perfekt)

• Er sieht nur, was im HTML der Seite steht. Bilder, die später per JavaScript hinzugefügt werden, und Hintergrundbilder, auf die innerhalb des Stylesheets von Webflow verwiesen wird, laden weiterhin von Webflow. Genauso Lottie-Animationsdateien und Schriften, auf die im CSS verwiesen wird.
• Seiten kommen bei jedem Besuch weiterhin von Webflow (standardmäßig), und genau das sorgt dafür, dass ein Publish sofort sichtbar ist. Die Ersparnis liegt bei den Dateien.
• Cache Reserve greift nicht. Laut Cloudflare-Doku wird Cache Reserve bei O2O umgangen, also liegen Dateien im normalen Edge-Cache, der selten genutzte Dateien früher rauswerfen kann. Die werden dann einfach neu geholt.
• Er macht dein JavaScript nicht schneller. Wenn deine Site wegen schwerer Interactions oder Skripten von Drittanbietern langsam ist, liegt das an der Site, nicht an den Bildern.
• Er kann kein Bild schrumpfen, das schon so klein ist, wie es nur geht.

Rollback

Wenn etwas furchtbar schiefgeht (sollte es nicht, aber du weißt ja, wie das ist): Öffne im Cloudflare-Dashboard deinen Worker, geh zu Settings → Domains & Routes und lösche die Route. Das wirkt sofort. Dann kommentierst du die routes-Zeile in der wrangler.jsonc wieder aus und committest, damit der nächste Build sie nicht zurückbringt. Deine Site lädt sofort wieder alles von Webflow, O2O und all deine anderen Cloudflare-Funktionen bleiben genau so, wie sie waren. Die gecachten Dateien werden einfach nicht mehr genutzt. Um ihn komplett zu entfernen, lösch auch den Worker.

Eine kurze Geschichte unseres Kampfs gegen die Plattform

Für die Nostalgiker, und damit du siehst, warum Version 6 so aussieht, wie sie aussieht:

• 2022: die Cassette-App und der SSL-Hack. Hat funktioniert, bis es nicht mehr funktioniert hat.
• 2023: unser erster Bild-Worker, nur für Bilder.
• Januar 2026: O2O kommt richtig an, und mit ihm die erste Version dieser Anleitung, mit CSS, JS und Schriften. Das Work-in-Progress-Video von damals findest du unten.
• Juli 2026: neu gebaut, um Seiten zu streamen statt zu puffern, was nebenbei auch Social-Bilder und Favicons repariert hat, die stillschweigend nie funktioniert hatten. Außerdem der Monat, in dem unsere eigene Wildcard-Route den Turnstile-Check unseres Scanners lahmgelegt hat. Lektion gelernt, Route festgezurrt.
• September 2026: das Loch mit dem geteilten Dateiserver gefunden und gestopft. Dann das Ganze als Version 6 neu gebaut, generisch für jede Webflow-Site, mit signierten Links, und auf GitHub gestellt.
• Oktober 2026: Version 6.1 mit Bildern in der richtigen Größe, eine zweite Site, die direkt aus dem öffentlichen Template installiert wurde, und automatisches Monitoring.

Keine Lust, es selbst zu machen?

Verständlich. DNS-Änderungen an einer Live-Site gehen an die Nerven, und nicht jeder will ein GitHub-Konto. Webflow-Performance ist so ein bisschen unser Ding (wir sind ein kleines Webflow-Studio, das ehrlich gesagt ungesund viel Zeit in Cloudflare-Dashboards verbringt), also schreib uns eine Nachricht, und wir richten dir das Ganze ein: O2O, den Worker, die OWASP-Ausnahme, die Checks. Und wenn du einen Kunden (oder deinen Chef) davon überzeugen musst, warum das alles wichtig ist, liefert unser Beitrag dazu, wie Seitengeschwindigkeit den Geschäftserfolg antreibt, die Argumente.

Häufig gestellte Fragen

Ist der Milk Moon Webflow Optimizer kostenlos?

Ja. Er ist Open Source unter der MIT-Lizenz auf GitHub. Du zahlst Cloudflare nur etwas, wenn du dich für ein Upgrade entscheidest. Gehst du über die Freikontingente hinaus (100.000 Worker-Anfragen pro Tag, 5.000 einzigartige Bildumwandlungen pro Monat), wird nichts berechnet: Bilder gehen unkonvertiert raus, bis der Monat zurückgesetzt wird, und der Worker läuft bis zum nächsten Tag nicht mehr (stell deine Route auf Fail Open, damit Besucher pures Webflow bekommen).

Darf ich einen Cloudflare Worker mit Webflow nutzen?

Ja, auf deiner Custom Domain. Webflow nennt O2O "den unterstützten Weg, Cloudflare-Funktionen vor Webflow zu betreiben", und Cloudflare führt Workers als O2O-kompatibel. Was die Nutzungsbedingungen von Webflow ausschließen, ist das Proxyen deiner *.webflow.io-Staging-Domain, und das macht dieser Worker nie. Der Webflow-Support debuggt den Worker nicht für dich, deshalb ist das Abschalten eine einzige Zeile.

Nutzt Webflow Cloudflare?

Ja. Webflow hat sein Hosting 2025 zu Cloudflare verlegt. Sites, die nach dem 21. April 2025 erstellt wurden, laufen bereits darauf, und ältere Sites wurden auf die neuen DNS-Einträge (cdn.webflow.com) umgestellt. Genau dieser Umzug macht O2O, und damit diesen Worker, überhaupt erst möglich.

Senkt es meine Webflow-Bandbreite?

Ja, bei Dateien. Webflow zählt jedes Byte, das sein CDN ausliefert. Mit dem Worker verlässt jedes Bild, jedes Stylesheet, jedes Skript und jede Schrift Webflow ungefähr einmal pro Cloudflare-Standort und wird danach bis zu ein Jahr lang aus dem Cache von Cloudflare ausgeliefert. Seiten kommen weiterhin von Webflow.

Was ist cdn.prod.website-files.com?

Das ist der Dateiserver von Webflow, auf dem deine Bilder, CSS, JavaScript und Schriften tatsächlich liegen. Weil das nicht deine Domain ist, kann deine Cloudflare-Zone darauf nichts cachen oder optimieren, selbst mit O2O. Der Worker schreibt diese Adressen um, sodass die Dateien über deine eigene Domain optimiert und gecached werden.

Muss ich Image Transformations in Cloudflare noch aktivieren?

Für Version 6 nicht. Der Worker wandelt Bilder selbst um, was Cloudflare auf jeder Zone erlaubt, auf der ein Worker läuft. Transformations müssen nur an sein, wenn du noch alte /cdn-cgi/image/-Links aus der vorherigen Version auslieferst.

Wie leere ich den Cache nach dem Veröffentlichen in Webflow?

Musst du nicht. Seiten werden vom Worker standardmäßig nicht gecached, also ist ein Publish sofort sichtbar, und geänderte Dateien bekommen von Webflow automatisch neue Adressen. Wenn du HTML_EDGE_TTL über 0 gesetzt hast, warte entweder so lange oder purge die Seite in Cloudflare unter Caching → Configuration.

Macht es meine Formulare, Turnstile oder Analytics kaputt?

Sollte es nicht. Turnstile, Tag Manager, Google Analytics, Google Fonts, Webflow Optimize und Skripte von Marketplace-Apps werden nie angefasst, und Seiten ohne die Markierung von Webflow gehen unangetastet durch. Teste nach der Installation trotzdem ein Formular, das dauert eine Minute.

Das war's

Lange Rede, kurzer Sinn: ein Button, ein Secret, eine Zeile, und deine Webflow-Site liefert kleinere Bilder von deiner eigenen Domain aus, aus dem Cache von Cloudflare, während Webflow nur noch einen Bruchteil von dem verschickt, was es früher verschickt hat. Wenn du ihn installierst, würde ich ehrlich gern hören, wie es läuft (und was er dir gespart hat). Meld dich bei uns, und schau dir den How-To-Bereich unseres Blogs für weitere Tutorials an.