Webflow am Edge: der Cloudflare-Asset-Proxy und Optimierungsleitfaden 2026

Webflow lief früher auf AWS und nutzte eine Zeit lang Fastly. Das ist ordentlich, aber bei großen Projekten, vor allem bildlastigen, hat uns Cloudflare deutlich mehr Tempo, bessere Verfügbarkeit, eine Vielzahl an Optimierungsoptionen und zusätzlich Workers geliefert. Anders als bei manchen anderen Plattformen war es aber nicht einfach, das DNS auf Cloudflare umzustellen. Webflow und Cloudflare vertrugen sich beim Proxying und Optimieren deiner Site über Cloudflare nicht gut.

Früher haben wir uns einen Hack ausgedacht, der die SSL-Einstellung und die Nicht-SSL-Verbindungsdaten nutzt, zusammen mit der Cassette-App, um Bilder zu cachen und zu optimieren. Irgendwann wurden die Apps aus Cloudflare entfernt, und mit viel Ausprobieren haben wir einen eigenen Worker gebaut, der Bilder von Webflow auf Cloudflare proxyt und cached.

Nun, die gute Nachricht: Das hat sich geändert.

Webflow ist zu Cloudflare umgezogen, und eine Weile steckten wir im Schwebezustand.

Das Großartige daran: Durch den Umzug zu Cloudflare funktioniert Orange-to-Orange (O2O) jetzt nativ. Keine hakeligen Workarounds mehr, keine Cassette-Apps, keine komplizierten Subdomains für deine Assets. Wenn du unseren früheren Beitrag zum Cachen von Webflow mit Cloudflare gelesen hast, kannst du das meiste davon getrost vergessen (die Teile darüber, warum man das überhaupt tun möchte, gelten weiterhin).

Wie sieht die aktuelle Lage beim Caching und Proxying über Cloudflare also aus? Da Webflow jetzt O2O unterstützt, ist die orange Wolke in deinen DNS-Einstellungen aktiv, von Webflow voll unterstützt, und SSL-Sorgen gehören der Vergangenheit an. Außerdem kannst du jetzt ganz einfach das umfangreiche Angebot an Sicherheitstools und Workers von Cloudflare nutzen.

ABER (und das ist der große Haken): Alle deine Assets, von Bildern bis CSS, liegen weiterhin auf einer Webflow-CDN-Domain. Da sie nicht auf DEINER DOMAIN liegen, hast du darüber weiterhin keine Kontrolle, es sei denn ...

In diesem Beitrag führen wir dich durch die Einrichtung eines Cloudflare Workers (im Grunde ein Webflow-Reverse-Proxy für deine Assets), der deine Webflow-Site so umbaut, dass praktisch alle Assets geproxyt und gecached werden. Wir reden von automatischer Bildoptimierung, Asset-Proxying und Edge-Caching, alles ausgeliefert von deiner eigenen Domain. Klingt spannend, oder? Früher haben wir uns nur auf Bilder konzentriert. Jetzt gehen wir einen Schritt weiter, decken mehr ab und machen die Nutzung einfacher als je zuvor.

Zur Erinnerung: Das hier ist anspruchsvolles Terrain. Wir haben das Skript intuitiver gemacht, aber bitte achte auf die Einrichtung. Bitte lies sorgfältig; ein Video folgt zu einem späteren Zeitpunkt. Legen wir los!

Unten findest du die Kurzanleitung. Mehr zu den Details des Skripts erfährst du, wenn du hier die MD-Datei auf GitHub besuchst, denn dort wird es deutlich ausführlicher.

Was wir erreichen wollen

Die Ausgangslage: Webflow hostet alle deine Assets auf eigenen CDN-Domains (cdn.prod.website-files.com, assets.website-files.com usw.). Da das nicht deine Domain ist, kann deine Cloudflare-Zone sie nicht anfassen, und das führt zu einigen Einschränkungen:

• Keine Bildoptimierung: Bilder werden unverändert ausgeliefert, ohne automatische AVIF- oder WebP-Konvertierung. Das machst du in Webflow, und spontan passiert nichts.
• CORS-Einschränkungen: domainübergreifende Anfragen können manchmal fehlschlagen
• Kein einheitliches Caching: deine Assets sind über verschiedene Domains verstreut
• Ärger mit Social Media: OG-Bilder sind für das Teilen nicht optimiert

Unser Cloudflare Worker versucht, vieles davon zu lösen, indem er das HTML deiner Site abfängt und alle Webflow-CDN-URLs so umschreibt, dass sie über deine Domain laufen.

Sobald alles eingerichtet ist, bekommst du:

• Automatische Formatkonvertierung: AVIF für moderne Browser, WebP für die anderen, oder was immer du bevorzugst
• Qualitätsoptimierung: konfigurierbare Komprimierung (wir nutzen 85 % als Standard, sieht großartig aus)
• Edge-Caching: alle Assets werden in den über 300 globalen Rechenzentren von Cloudflare gecached (bitte beachte, dass es kein Cache-Priming gibt)
• CORS-freie Auslieferung: alles kommt von deiner Domain
• Optimierung für Social Media: OG- und Twitter-Bilder werden aus Kompatibilitätsgründen in JPEG umgewandelt (bitte beachte, dass Cloudflare zwar in AVIF konvertieren kann, aber nicht zurück)

Und das Beste: Sobald das alles läuft, kannst du weitere Cloudflare-Funktionen obendrauf setzen. Page Rules, Cache Rules, WAF, Bot-Schutz, das volle Programm. Es ist jetzt deine Zone, also tob dich aus.

Aber es geht nicht nur um Bilder.

Der Worker proxyt und cached außerdem alle deine CSS-, JavaScript- und Schriftdateien über deine Domain (oder versucht es zumindest). Deine WOFF2s, deine TTFs, deine minifizierten JS-Bundles: Alles wird von Webflows CDN geholt, am Edge von Cloudflare gecached und mit passenden Cache-Headern von deiner Domain ausgeliefert. AVIF-Bilder? Die sind bereits optimiert, also überspringt der Worker die Transformation und proxyt sie einfach direkt. Favicons bekommen die volle Bildbehandlung. Kurz gesagt: Was Webflow von seinem CDN ausliefert, schnappen wir uns und machen es zu deinem.

Wir haben also noch eine Schippe draufgelegt. Unten findest du eine Anleitung im Überblick. Das Video zeigt nur, wie es läuft, aber sobald ich Zeit habe, nehme ich eine vollständige Anleitung auf. Vorerst kannst du der schriftlichen Anleitung folgen.

Teil 1: Deine Domain mit Cloudflare und Webflow einrichten

Es gibt zwei Wege, deine von Cloudflare verwaltete Domain mit Webflow zu verbinden:

1. Standard-Setup: Cloudflare übernimmt nur das DNS und Webflow liefert alles aus (Proxy AUS)
2. O2O-Setup: der Traffic läuft zuerst durch deine Cloudflare-Zone, dann zu Webflow (Proxy AN)

Wir wollen O2O, denn nur damit können wir Workers, Caching-Regeln, WAF und all die anderen Cloudflare-Extras nutzen. Aber wir gehen beide durch, damit du den Unterschied kennst.

Voraussetzungen

Deine Webflow-Site muss auf der Infrastruktur von Cloudflare laufen. Sites, die nach dem 21. April 2025 erstellt wurden, sind bereits dort. Bei älteren Sites prüfst du in deinen Workspace-Einstellungen unter Domain Updates, ob du zuerst migrieren musst.

Standard-DNS-Setup (ohne O2O)

Wenn Cloudflare nur dein DNS verwalten soll, ohne Proxying (das steht so in den Standardanweisungen von Webflow):

Für deine Root-Domain (@):

• Type: A
• Name: @
• Value: 198.202.211.1
• Proxy status: DNS only (graue Wolke)

Für www:

• Type: CNAME
• Name: www
• Target: cdn.webflow.com
• Proxy status: DNS only (graue Wolke)

Das funktioniert problemlos, aber du bekommst keine Cloudflare-Funktionen über das DNS hinaus. Der Traffic geht direkt zu Webflow.

O2O-Setup (das wollen wir)

Um Orange-to-Orange zu aktivieren und die Funktionen von Cloudflare tatsächlich zu nutzen, brauchst du geproxyte CNAME-Einträge:

Für deine Root-Domain (@):

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

Für www:

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

Wichtig: Lösche alle bestehenden A-Einträge, die auf 198.202.211.1 zeigen. Beides gleichzeitig geht nicht. Für O2O braucht es CNAME-Einträge mit aktiviertem Proxy.

Wenn du weitere Subdomains hast (etwa blog.yourdomain.com), füge für jede ebenfalls einen geproxyten CNAME hinzu.

SSL/TLS-Einstellungen

Gehe in deinem Cloudflare-Dashboard zu SSL/TLS und stelle den Verschlüsselungsmodus auf Full (strict).

Die Domain in Webflow hinzufügen

Weiter in Webflow:

1. Gehe zu Site settings → Publishing → Production
2. Füge deine Domain hinzu (Root und www)
3. Veröffentliche deine Site

Zur Warnung "Update needed"

Das passiert: Sobald die orange Wolke aktiv ist, kann Webflow deine DNS-Einträge nicht mehr sehen. Deshalb beschwert es sich, oder zumindest kann es das tun. In deinen Publishing-Einstellungen siehst du dann "Update needed" oder "Update pending".

Ignoriere es.

Das ist erwartetes Verhalten. Die Verifizierung von Webflow kann nicht durch den Proxy hindurchsehen. Wenn deine Site korrekt lädt, ist alles in Ordnung. Du kannst ganz normal weiter veröffentlichen. Bei mir blieb die Warnung stehen, in manchen Fällen verschwindet sie auch wieder.

Prüfen, ob es funktioniert

Rufe deine Site auf. Wenn sie lädt, hast du es geschafft. Außerdem kannst du:

• SSL Labs nutzen, um dein SSL-Zertifikat zu testen
• whatsmydns.net nutzen, um zu bestätigen, dass deine Domain auf Cloudflare-IPs aufgelöst wird
• in den Response-Headern nach cf-ray suchen (zeigt an, dass Cloudflare in der Kette sitzt)

Gut, O2O steht. Jetzt kommt der spaßige Teil.

Teil 2: Die benötigten Cloudflare-Funktionen aktivieren

Bevor wir den Worker deployen, müssen wir in Cloudflare ein paar Dinge aktivieren und sicherstellen, dass die richtigen Abos aktiv sind.

Image Transformations aktivieren

Das ist die Geheimzutat, mit der Cloudflare deine Bilder spontan konvertiert und optimiert.

1. Gehe zum Cloudflare Dashboard → Deine Zone
2. Navigiere zu Images → Transformations
3. Klicke auf Enable Image Transformations

Ohne das funktionieren die /cdn-cgi/image/-URLs nicht, und deine Bilder liefern einfach 404. Nicht ideal.

Kosten: Im kostenlosen Tarif bekommst du 5.000 einzigartige Transformationen pro Monat. In einem kostenpflichtigen Tarif sind die ersten 5.000 einzigartigen Transformationen ebenfalls inklusive, danach kostet es 0,50 $ pro 1.000 einzigartige Transformationen im Monat. Für die meisten Webflow-Sites reicht der kostenlose Tarif zum Einstieg locker.

Erlaubte Origins hinzufügen

Weiterhin unter Images → Transformations klickst du auf Sources und fügst diese Origins hinzu:

Origin:
‍

• ‍cdn.prod.website-files.com
• assets.website-files.com
• assets-global.website-files.com
• ‍uploads-ssl.webflow.com
• cdn.webflow.com
• ‍www.yourdomain.com Entscheidend!

Der letzte Eintrag ist entscheidend und wird leicht übersehen. Die Transform-URLs verweisen auf deine eigene Domain als Quelle (weil wir über /img-original/ proxyen), also braucht Cloudflare die Erlaubnis, von sich selbst abzurufen. Meta, wir wissen.

Workers aktivieren

Du musst Workers für deine Zone aktivieren.

1. Gehe im Cloudflare Dashboard zu Workers & Pages
2. Wenn du Workers noch nicht genutzt hast, wirst du aufgefordert, eine Subdomain einzurichten

Kosten: Der kostenlose Tarif bietet 100.000 Anfragen pro Tag. Das ist eine Menge. Der kostenpflichtige Tarif kostet 5 $/Monat für 10 Millionen Anfragen, falls du mehr brauchst.

Teil 3: Den Worker erstellen

Jetzt zum eigentlichen Worker. Hier passiert die Magie.

Schritt 1: Einen neuen Worker erstellen

1. Gehe zu Workers & Pages
2. Klicke auf Create Application → Create Worker
3. Gib ihm einen Namen (etwa webflow-optimizer oder site-cache)
4. Du siehst eine Hello-World-Vorlage: lösche alles daraus

Schritt 2: Den Worker-Code einfügen

Wir haben ein vollständiges Worker-Skript, das alles erledigt. Es ist eine ziemlich lange JavaScript-Datei, die:

• HTML-Antworten von Webflow abfängt
• alle Bild-URLs so umschreibt, dass sie Cloudflare Image Resizing nutzen
• AVIF-Bilder direkt proxyt (sie sind bereits optimal)
• CSS, JS und Schriften proxyt und cached
• OG-/Twitter-Bilder fürs Teilen in sozialen Netzwerken behandelt
• passende CORS-Header hinzufügt
• alles am Edge cached

Füge das vollständige Worker-Skript ein (du findest es auf unserem GitHub oder hier auf der Seite).

Schritt 3: Speichern und deployen

Klicke auf Save and Deploy. Der Worker ist jetzt live, tut aber noch nichts, weil wir ihm noch nicht gesagt haben, wo er laufen soll.

Teil 4: Umgebungsvariablen

Der Worker nutzt Umgebungsvariablen, damit du ihn konfigurieren kannst, ohne den Code zu bearbeiten. Gehe zu deinem Worker → Settings → Variables and Secrets.

Erforderliche Variable

Variable: DOMAIN

Value: Deine Domain (ohne https://), in unserem Fall also www.milkmoonstudio.com

Damit weiß der Worker, welche Domain er in den umgeschriebenen URLs verwenden soll. Fehlt sie, prüft der Code die aktuelle Domain und nutzt diese als Fallback.

Optionale Variablen (mit sinnvollen Standardwerten, alle Variablen haben Fallbacks)

Variable: IMAGE_FORMAT

Value: auto", webp" oder avif

‍

Variable: IMAGE_QUALITY

Value: 85 (Qualität 1-100, 85 ist ein guter Kompromiss)

‍

Variable: OG_IMAGE_FORMAT

Value: jpeg (Format für Bilder zum Teilen in sozialen Netzwerken)

‍

Variable: OG_IMAGE_QUALITY

Value: 80 (Qualität für OG-Bilder)

‍

Variable: EDGE_CACHE_TTL

Value: 31536000 (Dauer des Edge-Caches in Sekunden) (Standard: 1 Jahr)

‍

Variable: BROWSER_CACHE_TTL

Value: 604800 (Dauer des Browser-Caches in Sekunden, Standard: 1 Woche)

‍

Variable: CATCH_ALL_EXTERNAL

Value: false (Auch Bilder verarbeiten, die nicht vom Webflow-CDN stammen; sehr experimentelle Funktion, und für beliebige Domains muss Image Transformations aktiviert sein)

‍

Empfehlungen:

• Lass IMAGE_FORMAT auf auto: Browsern mit Unterstützung wird AVIF ausgeliefert, allen anderen WebP
• IMAGE_QUALITY mit 85 sieht bei den meisten Bildern großartig aus. Geh auf 70-75 runter, wenn du wirklich jedes Byte sparen willst
• Lass OG_IMAGE_FORMAT auf jpeg: manche soziale Plattformen kommen bei Vorschauen immer noch nicht mit AVIF/WebP klar

Teil 5: Die Worker-Route einrichten

Hier kommt ein entscheidender Punkt, an dem viele hängen bleiben. Der Worker muss auf deiner eigenen Domain laufen, nicht auf der *.workers.dev-Subdomain. Die Cache API funktioniert auf workers.dev nicht, das heißt: kein Caching, und damit wäre der ganze Sinn dahin.

Die Route hinzufügen

1. Gehe in deinem Worker zu Settings → Domains & Routes
2. Klicke auf Add → Route
3. Konfiguriere:
   • Route: *yourdomain.com/*
   • Zone: Wähle deine Zone aus
4. Klicke auf Add Route

Das * am Anfang erfasst sowohl www.yourdomain.com als auch yourdomain.com. Das /* am Ende erfasst alle Pfade.

Wenn du nur www nutzt, kannst du genauer sein: www.yourdomain.com/*

Teil 6: Wie das Ganze funktioniert

Schauen wir uns an, was unter der Haube tatsächlich passiert. Dieser Teil ist für die Neugierigen (und für den Moment, in dem unweigerlich etwas schiefgeht und du debuggen musst).

Der Request-Ablauf

Wenn jemand deine Site besucht:

1. Die Anfrage erreicht Cloudflare: zuerst deine Zone (O2O)
2. Der Worker fängt sie ab: prüft, ob es eine HTML-Anfrage ist
3. Abruf von Webflow: holt das HTML (am Edge gecached)
4. URLs transformieren: schreibt alle Webflow-CDN-URLs um
5. Transformiertes HTML zurückgeben: der Browser erhält die veränderte Seite

Wenn der Browser anschließend ein Bild anfordert:

1. Die Anfrage trifft auf /cdn-cgi/image/format=auto,quality=85/https://yourdomain.com/img-original/...
2. Cloudflare Image Resizing: parst die Transform-URL
3. Quelle abrufen: holt das Original von deinem /img-original/-Endpunkt
4. Der Worker proxyt: /img-original/ ruft vom Webflow-CDN ab
5. Transformieren: konvertiert zu AVIF/WebP und wendet die Qualität an
6. Cachen: Original und transformierte Version werden am Edge gecached
7. Ausliefern: das optimierte Bild geht an den Browser

URL-Struktur

So sieht eine transformierte URL aus:

Original (in Webflow):

https://cdn.prod.website-files.com/63565c108c96756a59b92502/image.jpg

Transformiert (in deinem HTML):

https://yourdomain.com/cdn-cgi/image/format=auto,quality=85/https://yourdomain.com/img-original/https%3A%2F%2Fcdn.prod.website-files.com%2F63565c108c96756a59b92502%2Fimage.jpg

Aufgeschlüsselt:

• https://yourdomain.com/cdn-cgi/image/: der Image-Resizing-Endpunkt von Cloudflare
• format=auto,quality=85/: die Transformationsparameter
• https://yourdomain.com/img-original/: unser Proxy-Endpunkt
• https%3A%2F%2Fcdn.prod...: die URL-kodierte Original-Bild-URL

Was transformiert und was nur geproxyt wird

• ‍PNG, JPG, WebP, GIF: Optimiert über Cloudflare Image Resizing /cdn-cgi/image/ → /img-original/
• ‍SVG: Bereinigt (Skripte entfernt), Format bleibt erhalten /cdn-cgi/image/ → /img-original/
• ‍AVIF: Nur geproxyt (bereits optimal) /img-cache/
• CSS, JS: Geproxyt und gecached /asset-cache/
• ‍Schriften: (woff, woff2, ttf, otf, eot) geproxyt und gecached /asset-cache/ (very experimental)
• ‍Favicons: Als Bilder optimiert /cdn-cgi/image/ → /img-original/
• ‍OG-/Twitter-Bilder: In JPEG konvertiert /cdn-cgi/image/ → /img-original/

Teil 7: Dein Setup testen

Zeit sicherzustellen, dass alles richtig funktioniert.

Grundlegende Prüfungen

1. Seitenquelltext ansehen

• Rufe deine Site auf
• Rechtsklick → Seitenquelltext anzeigen
• Suche nach /cdn-cgi/image/: es sollte in Bild-URLs auftauchen
• Suche nach /asset-cache/: es sollte in CSS- und JS-URLs auftauchen

Wenn du diese siehst, läuft der Worker und transformiert dein HTML.

2. Den Network-Tab prüfen

• Öffne die DevTools (F12 oder Cmd+Option+I)
• Gehe zum Network-Tab
• Lade die Seite neu
• Filtere nach "Img"
• Prüfe, dass die Bild-URLs von deiner Domain kommen, nicht vom Webflow-CDN

3. Cache-Header verifizieren: Klicke im Network-Tab auf ein Bild und prüfe die Response Headers (der Cloudflare-eigene Header cf-cache-status meldet HIT oder MISS auf dieselbe Weise):

• X-Cache: HIT = aus dem Cache von Cloudflare ausgeliefert (gut!)
• X-Cache: MISS = erste Anfrage, jetzt gecached (ebenfalls in Ordnung)
• Content-Type: image/avif oder image/webp = Formatkonvertierung funktioniert

4. Das Teilen in sozialen Netzwerken testen

• Nutze den Sharing Debugger von Facebook
• Nutze ein Tool für Karten-Vorschauen wie opengraph.xyz oder den Beitragseditor von X (der alte Card Validator von Twitter zeigt keine Vorschauen mehr an)
• Prüfe, dass OG-Bilder fehlerfrei laden

Die DrFlare-Erweiterung nutzen

Der einfachste Weg, dein Setup zu testen, ist die DrFlare-Erweiterung für Chrome. Starte sie über die DevTools und lade die Seite neu. Du siehst detaillierte Statistiken und kannst mit der Maus über Bilder fahren, um eine Analyse direkt auf der Seite zu bekommen. Sie wurde eingestellt, aber als DrFlare Reloaded, hier erhältlich, wieder zum Leben erweckt.
‍

Denk bitte daran, den Browser neu zu laden, sobald DrFlare geöffnet ist.

Teil 8: Fehlerbehebung

Manchmal geht etwas schief. So behebst du die häufigsten Probleme.

Bilder liefern 404

Symptome: Bilder laden nicht, 404-Fehler in der Konsole.

Checkliste:

• ✅ Image Transformations in Cloudflare aktiviert?
• ✅ Deine Domain zu den Allowed Origins hinzugefügt?
• ✅ Worker-Route aktiv und korrekt?
• ✅ DOMAIN-Umgebungsvariable richtig gesetzt?

Prüfe die Worker-Logs: Cloudflare Dashboard → Workers → Dein Worker → Logs

Assets laden weiterhin vom Webflow-CDN

Symptome: CSS-/JS-URLs wurden nicht transformiert.

Checkliste:

• ✅ Worker auf einer Route deiner eigenen Domain deployt (nicht *.workers.dev)?
• ✅ Routenmuster korrekt? (z. B. *yourdomain.com/*)
• Browser-Cache leeren und neu laden (Ctrl/Cmd + Shift + R)

Sieh dir den Seitenquelltext an. Wenn die URLs nicht transformiert sind, läuft der Worker nicht auf dieser Route.

OG-Bilder funktionieren in sozialen Netzwerken nicht

Symptome: Social-Vorschauen zeigen kaputte Bilder.

Prüfen:

• Nutze den Sharing Debugger von Facebook oder ein Tool für Karten-Vorschauen, um den tatsächlichen Fehler zu sehen
• Prüfe, ob OG_IMAGE_FORMAT auf jpeg gesetzt ist
• Prüfe, ob das Meta-Tag im Seitenquelltext transformiert wurde

Webflow zeigt "Update needed" für die Domain

Das ist erwartet! Ist der Cloudflare-Proxy aktiv, kann Webflow deine DNS-Einträge nicht sehen. Wenn deine Site korrekt lädt, ignoriere diese Warnung.

525 Handshake Error

Das bedeutet meist, dass mit deinem SSL-Setup etwas nicht stimmt:

• Prüfe, ob der SSL/TLS-Modus in Cloudflare auf Full (strict) steht
• Stelle sicher, dass keine widersprüchlichen SSL-Einstellungen vorliegen

Teil 9: Kosten

Reden wir über Geld. Was kostet dich das Ganze?

Cloudflare Workers

• Kostenloser Tarif: 100.000 Anfragen/Tag
• Kostenpflichtig: 5 $/Monat für 10 Millionen Anfragen

Image Transformations

• Kostenloser Tarif: 5.000 einzigartige Transformationen/Monat
• Kostenpflichtig: die ersten 5.000 einzigartigen Transformationen inklusive, danach 0,50 $ pro 1.000 einzigartige Transformationen/Monat

Für eine typische Webflow-Site

Die Caching-Strategie senkt die Kosten erheblich:

• HTML am Edge gecached → weniger Origin-Anfragen
• Originalbilder gecached → die Transformation passiert nur einmal pro Bild
• Transformierte Bilder gecached → bei wiederholten Besuchen vom Edge ausgeliefert
• 1 Jahr TTL → Bilder bleiben gecached, bis du sie purgst
• Denk daran: Cache und Page Rules ermöglichen eine komplexere Cache-Strategie. Blogseiten können zum Beispiel weniger aggressiv gecached werden als eine Startseite, weil Beiträge häufiger aktualisiert werden, während statische Seiten oft fast unbegrenzt gecached werden können.

Den Cache leeren

Sobald deine Caching-Strategie steht, denk daran, dass Änderungen nicht sofort sichtbar sein müssen. Wenn du den Edge-Cache für eine Seite oder ein Asset auf eine Woche gesetzt hast, wird die gecachte Version am Edge erst nach Ablauf dieser Woche verworfen.

Um den Cache im Cloudflare Dashboard zu leeren, gehe zu Caching → Configuration und nutze entweder Custom Purge (um gezielter festzulegen, was geleert wird) oder Purge Everything (leert den gesamten Cache).

Danach denk daran, den Browser-Cache zu leeren oder im privaten Modus bzw. Inkognito-Modus zu testen. Wenn es nicht am Cache, sondern am trägen DNS liegt, haben wir einen Beitrag über das Beschleunigen der DNS-Auflösung beim Veröffentlichen deiner Webflow-Site, schau ihn dir an.

Custom Purge bietet die folgenden Optionen für gezieltes Leeren.

Den Cache per Webhook im Webflow-Einstellungsbereich purgen

Du kannst auch beim Veröffentlichen in Webflow purgen, indem du in deinen Webflow-Einstellungen einen Webhook hinzufügst.

Webflow → Cloudflare Cache Purge Webhook

Das Wichtigste in Kürze:

Der Ablauf

1. Webflow löst einen Webhook aus, wenn du deine Site veröffentlichst
2. Etwas empfängt diesen Webhook und ruft die API von Cloudflare auf, um den Cache zu purgen

Der Haken: Cloudflare hat keinen direkten Endpunkt zum Empfangen von Webhooks, also brauchst du einen Vermittler (Cloudflare Worker, Zapier, Make oder eine einfache Serverless-Funktion).

Einrichtungsschritte

1. In Webflow

• Gehe zu Site settings → Apps & integrations → Webhooks
• Füge einen Webhook mit dem Trigger-Typ Site publish hinzu
• Lass ihn auf die URL deines Vermittlers zeigen (Worker, Zapier usw.)

2. In Cloudflare

• Hole dir deine Zone ID (auf der Übersichtsseite deiner Domain)
• Erstelle ein API Token mit der Berechtigung Zone.Cache Purge

3. Der Vermittler (Beispiel mit Cloudflare Worker)

Dein Worker empfängt den Webflow-Webhook und ruft den Purge-Endpunkt von Cloudflare auf:

POST https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache

Mit dem Body: {"purge_everything": true}

Dokumentation

• Webflow Webhooks: https://developers.webflow.com/data/docs/working-with-webhooks
• Cloudflare Purge Cache API: https://developers.cloudflare.com/api/resources/cache/methods/purge/‍
  ‍

Teil 10: Einschränkungen

Nichts ist perfekt. Das solltest du wissen:

Bekannte Einschränkungen

• ‍Cache Reserve nicht verfügbar: Webflow nutzt O2O-Proxying, das Cache Reserve umgeht. Assets werden nur am Edge gecached.
• ‍JSON-LD wird nicht transformiert: URLs in strukturierten Daten werden nicht verändert. Suchmaschinen kommen mit den Original-URLs problemlos klar.‍
• Regex-basierte Transformation: Mehrere Durchläufe über das HTML. Für typische Seiten (<200 KB) akzeptabel.

Was nicht funktioniert

• Data-URLs (data:image/...): inline, es gibt nichts zu proxyen
• Blob-URLs (blob:...): vom Browser erzeugt, lassen sich nicht proxyen
• Relative URLs: liegen bereits auf deiner Domain
• Assets außerhalb des Webflow-CDN: außer bei CATCH_ALL_EXTERNAL=true

Dynamische Inhalte

Der Worker transformiert das HTML nur bei der ersten Antwort. Bilder, die nach dem Laden der Seite per JavaScript hinzugefügt werden, werden möglicherweise nicht transformiert, es sei denn, sie stehen auch im ursprünglichen HTML. Wenn du viel clientseitiges Rendering einsetzt, behalte das im Hinterkopf.

Anleitung zum Zurückrollen

Falls etwas ganz gewaltig schiefgeht (wahrscheinlich nicht, aber sicher ist sicher):

Schnell deaktivieren (Worker behalten)

1. Gehe zu Worker → Settings → Domains & Routes
2. Lösche die Route
3. Die Site wird sofort wieder direkt von Webflow ausgeliefert
4. Schalte den Developer Mode ein, um den Cache zu umgehen

Vollständig entfernen

1. Lösche die Worker-Route
2. Lösche den Worker selbst
3. (Optional) Deaktiviere Image Transformations
4. (Optional) Entferne die Allowed Origins

Deine Site kehrt zum normalen Webflow-Hosting zurück, wobei der O2O-Proxy weiterhin aktiv bleibt. Die übrigen Cloudflare-Funktionen wie WAF und Bot-Schutz stehen dir weiterhin zur Verfügung.

Häufig gestellte Fragen

Nutzt Webflow Cloudflare?

Ja. Webflow hat sein Hosting 2025 auf Cloudflare verlegt. Sites, die nach dem 21. April 2025 erstellt wurden, laufen bereits auf Cloudflare, und bei älteren Sites mussten die Custom Domains auf die neuen DNS-Einträge von Webflow umgestellt werden (der cdn.webflow.com-CNAME und der 198.202.211.1-A-Eintrag). Genau dieser Umzug macht O2O möglich, und deshalb sind die alten Hacks aus unseren früheren Beiträgen nicht mehr nötig.

Wie richte ich Cloudflare CDN und SSL für eine Webflow-Site ein?

Richte die Nameserver deiner Domain auf Cloudflare aus, füge geproxyte CNAME-Einträge für @ und www hinzu, die auf cdn.webflow.com zeigen, stelle SSL/TLS auf Full (strict), füge dann die Domain in Webflow unter Site settings → Publishing → Production hinzu und veröffentliche. Das ist O2O, und Teil 1 oben führt dich Schritt für Schritt durch. Wenn du Cloudflare nur für das DNS willst, nutze stattdessen die Einträge mit grauer Wolke (nur DNS), dann bekommst du aber weder Caching noch Optimierung.

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

Das ist das Asset-CDN von Webflow, die Domain, auf der deine Bilder, CSS, JavaScript und Schriften tatsächlich liegen. Da es nicht deine Domain ist, kann deine Cloudflare-Zone nichts davon cachen oder optimieren, selbst mit aktiviertem O2O. Der Worker in diesem Beitrag löst das, indem er diese URLs umschreibt, sodass die Dateien über deine eigene Domain geproxyt, optimiert und gecached werden.

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

Webflow kümmert sich beim Veröffentlichen um seinen eigenen Cache, aber alles, was in deiner Cloudflare-Zone gecached ist, bleibt dort, bis die TTL abläuft. Purge es im Cloudflare Dashboard unter Caching → Configuration (Custom Purge oder Purge Everything) oder automatisiere es mit einem Site-publish-Webhook, der die Purge-API von Cloudflare aufruft, wie im Cache-Abschnitt oben beschrieben. Leere danach deinen Browser-Cache oder teste in einem privaten Fenster.

Zusammenfassung

Und das war's. Du hast jetzt eine ordentlich aufgemotzte Webflow-Site, die über Cloudflare läuft, mit Bildoptimierung, Asset-Caching und allem Edge-Komfort, den du dir wünschen kannst.

Das Beste daran? Sobald das läuft, kannst du weitere Cloudflare-Funktionen dazuschalten. Richte Page Rules ein (oder Cache Rules, die Page Rules ablösen) für gezieltes Caching-Verhalten. Füge WAF-Regeln für die Sicherheit hinzu. Konfiguriere Bot-Schutz. Nutze Waiting Room, wenn du Traffic-Spitzen erwartest. Es ist jetzt deine Zone. Du musst ein bisschen herumprobieren, um das Beste herauszuholen.

Ein großer Teil der Optimierung entsteht durch das Experimentieren mit Caching, Page Rules und Co.

Wir betreiben dieses Setup seit einer Weile produktiv, und die Leistungsgewinne scheinen solide. Schnellere Ladezeiten, bessere Core Web Vitals, kleinere Bilddateien und zufriedenere Kunden. Wenn du einen Kunden (oder deinen Chef) davon überzeugen musst, warum das wichtig ist, liefert unser Beitrag dazu, wie Seitengeschwindigkeit den Geschäftserfolg antreibt, die Argumente.

Wenn du auf Probleme stößt oder Fragen hast, schreib uns. Wir unterhalten uns immer gern über die Performance-Optimierung von Webflow (das ist sozusagen unser Ding). Wir melden uns so schnell wie möglich.

Schau dir auch den How-To-Bereich unseres Blogs für weitere Tutorials an. Wir haben Beiträge zu allem Möglichen, vom Tag-Manager-Setup bis zu dynamischen Schriftgrößen.

Bis zum nächsten Mal, bau weiter. ✌️

Diese Tests wurden zum Zeitpunkt der Veröffentlichung durchgeführt, daher sollte all der übliche Kram, den ich gerade auf unserer Site teste, laufen.

‍