Die beste Cloudflare-Konfiguration, um die Core Web Vitals zu bestehen

Core Web Vitals mit Cloudflare optimieren: Was du aktivieren solltest und was nicht

Cloudflare bietet eine Vielzahl an Einstellungen, die deine Core Web Vitals beeinflussen können – positiv wie negativ. Während manche Optionen die Performance verbessern, verursachen andere Verzögerungen oder stören das Rendering der Seite. Schauen wir uns die wichtigsten Cloudflare-Optionen an und wann du sie aktivieren solltest.

Zuletzt geprüft von Arjen Karel im Februar 2026

Häufige Fragen zum Cloudflare-Setup: Ich prüfe regelmäßig Cloudflare-Setups für Kunden. Ich könnte ganze Bücher über das Einrichten eines CDNs wie Cloudflare schreiben, doch die meisten Fragen drehen sich um ein simples „Soll ich diese Option aktivieren?“. Dieser Artikel beantwortet genau diese Fragen und zeigt dir die wichtigsten Abwägungen für Cloudflare-Einstellungen rund um die Core Web Vitals.

Free vs. Pro: Lohnt sich ein Upgrade?

Speed > Optimierung

Polish

Polish optimiert Bilder, die über deine Cloudflare-Domain laufen: Es komprimiert sie, entfernt Metadaten und konvertiert sie optional nach WebP. Eine vollständige Anleitung zur Bildoptimierung findest du unter Bilder für die Core Web Vitals optimieren.

Geringere Dateigrößen verbessern meist den Largest Contentful Paint, da sie die Ladedauer der Bildressource verkürzen. Da der LCP jedoch von vielen weiteren Faktoren neben der Ladezeit von Bildern abhängt, solltest du keine drastischen Sprünge erwarten.

Empfehlung: Aktivieren und für die besten Ergebnisse „Lossy WebP“ wählen. Beachte, dass Polish keine Konvertierung nach AVIF unterstützt; für AVIF benötigst du Cloudflare Image Resizing (einen separaten, kostenpflichtigen Dienst).

Mirage (deprecated)

Mirage wurde von Cloudflare am 15. September 2025 eingestellt und auf allen Domains automatisch deaktiviert. Moderne Browser unterstützen lazy loading mittlerweile nativ über das Attribut loading="lazy", was den JavaScript-basierten Ansatz von Mirage überflüssig macht.

Mirage optimierte Bilder früher abhängig von den Netzwerkbedingungen. Diese Umsetzung war „slow by design“: Sie blockierte Bilder, bis die Netzwerkgeschwindigkeit gemessen war. Diese Blockade konnte zu Layout Shifts und ironischerweise zu einem langsameren Largest Contentful Paint führen.

Empfehlung: Diese Einstellung gibt es nicht mehr. Wenn du sie in älteren Anleitungen siehst, ignoriere sie.

Speed Brain

Speed Brain nutzt die Speculation Rules API, um künftige Navigationen per Prefetch vorab zu laden und so die Time to First Byte zu verkürzen. Speculation Rules sind extrem effektiv, um sämtliche Core Web Vitals einschließlich des Largest Contentful Paint zu verbessern. Speed Brain steht in allen Tarifen zur Verfügung (auch im kostenlosen) und nutzt aktuell die Eagerness-Stufe conservative. Dabei wird ein Prefetch erst ausgelöst, wenn ein Nutzer kurz davor ist, auf einen Link zu klicken.

Ich rate davon ab, dich auf Speed Brain zu verlassen: Es ist einfach, Speculation Rules manuell zu konfigurieren, und weitaus effektiver als Cloudflares Pauschallösung. Bei einer manuellen Konfiguration wählst du deine eigenen Eagerness-Stufen selbst, sprichst gezielt bestimmte URLs an und kannst Prerendering statt nur Prefetching nutzen.

Empfehlung: Deaktivieren und Speculation Rules manuell konfigurieren. Wenn du sie nicht selbst konfigurierst, ist ein aktives Speed Brain immer noch besser als gar keine Speculation Rules.

Cloudflare Fonts

Cloudflare Fonts automatisiert das Self-Hosting von Fonts. Der Ansatz ist hervorragend: Hostest du wichtige Ressourcen selbst, entfallen neue, externe Verbindungen. Und eine bestehende Verbindung zu deiner über Cloudflare betriebenen Seite wiederzuverwenden, ist grundsätzlich schneller.

Effektiver ist es, dir 15 Minuten Zeit zu nehmen und Font-Dateien manuell selbst zu hosten. Viele CMS-Systeme lassen das allerdings nicht zu. In diesem Fall ist Cloudflare Fonts eine absolut valide Option. Beachte aber: Cloudflare Fonts befindet sich (seit 2023) nach wie vor in der Beta-Phase und funktioniert nicht, wenn APO aktiviert ist.

Empfehlung: Standardmäßig deaktivieren; nur aktivieren, wenn manuelles Self-Hosting keine Option ist.

Early Hints

Early Hints beschleunigen die Auslieferung kritischer Ressourcen (wie Styles, Fonts oder Bilder): Sie kündigen diese an, noch bevor das eigentliche HTML an den Browser gesendet wird. Um einen Resource Hint über Cloudflare zu senden, liest Cloudflare deine Response-Header aus und übernimmt die Hints von dort.

Wenn du dich damit wohlfühlst, Resource Hints in HTTP-Response-Headern mitzusenden, empfehle ich dieses Feature ausdrücklich. Sei dir aber bewusst: Resource Hints in Headern sind für dein Entwicklerteam oft deutlich schwerer zu durchschauen als Resource Hints im <head> der Seite. Falsch konfiguriert bremsen sie die Seite aus, statt sie zu beschleunigen. Geh also vorsichtig damit um. Obwohl Early Hints seit Jahren verfügbar sind, liegt die Nutzungsrate laut dem Web Almanac 2025 immer noch unter 3 %.

Empfehlung: Nur aktivieren, wenn du die Header für Resource Hints korrekt mitsendest.

Auto Minify

Cloudflare kann dein HTML, CSS und JavaScript on the fly minifizieren. Die HTML-Minifizierung entfernt Whitespace sowie Kommentare und reduziert so die Übertragungsgröße leicht. Dasselbe gilt für CSS und JavaScript.

Empfehlung: Aktiviere die HTML-Minifizierung. Für CSS und JavaScript liefert eine Minifizierung zur Build-Zeit (während deines Deployment-Prozesses) bessere Ergebnisse als Cloudflares On-the-fly-Ansatz. Hast du keinen Build-Prozess, kannst du problemlos alle drei aktivieren.

Rocket Loader

Rocket Loader verzögert sämtliches JavaScript einer Webseite per Defer: Er hält Skripte vorübergehend zurück und injiziert sie kurz darauf in die Seite. Ein fieser (oder genialer, je nach Sichtweise) Trick, der viele Checks und Hacks erfordert, damit er in allen Browsern funktioniert. Zudem versteckt er die Skripte vor dem Preload-Scanner – einem Mechanismus, der das Laden kritischer Ressourcen eigentlich beschleunigen soll.

Aus diesen Gründen halte ich nichts davon, Rocket Loader blind zu aktivieren. Skripte sollten nach ihrer Priorität eingeplant werden: Kritische Skripte müssen früh laden und ausführen, während unwichtige Skripte warten können, bis der Browser idle ist.

Cloudflares Rocket Loader macht genau das nicht. Er blockiert alle Skripte pauschal und injiziert sie irgendwann ohne Rücksicht auf deren Wichtigkeit. Rocket Loader priorisiert lediglich andere Ressourcen wie das LCP-Element, Fonts und Styles gegenüber Skripten. Obendrein nutzt Rocket Loader den unload-Event-Handler – eine veraltete API, die verhindert, dass der Back-Forward-Cache (bfcache) des Browsers funktioniert. Beim Vor- und Zurücknavigieren wird die Seite dadurch jedes Mal komplett neu geladen, statt blitzschnell wiederhergestellt zu werden.

Erlaubt dein CMS kein Defer oder feineres Timing für Skripte, ist Rocket Loader unter Umständen deine beste Option. Für die meisten Seiten ist es jedoch weitaus effektiver, Skripte manuell zu steuern.

Empfehlung: Deaktivieren und Skripte manuell steuern. Nur aktivieren, wenn du keine andere Möglichkeit hast, die Skriptausführung zu verzögern oder zu kontrollieren.

Automatic Platform Optimization für WordPress

Cloudflares APO speichert komplette Seiten auf seinen Edge-Servern zwischen – eine Technik namens Full-Page Edge Caching. Richtig umgesetzt verbessert das die Time to First Byte (und in der Folge LCP und FCP) für bestimmte Besucher spürbar!

Die Sache hat jedoch einen Haken: Full-Page Edge Caching muss häufig automatisch umgangen werden. Meldet sich ein Nutzer beispielsweise an oder legt Artikel in den Warenkorb, schaltet sich APO automatisch ab, da der Seiteninhalt nun personalisiert ist. Eine generische Seite aus dem Cache auszuliefern, ist dann keine Option mehr. Da APO für alle Arten von Websites funktionieren muss, wird der Cache viel öfter umgangen, als es für deine Seite eigentlich nötig wäre. Deshalb ist eine manuelle Cache-Konfiguration fast immer effektiver als Cloudflares APO.

Empfehlung: Aktiviere APO – oder noch besser: Konfiguriere eigene Regeln für das Full-Page Edge Caching, um besser zu steuern, wann der Cache umgangen wird.

HTTP/2, HTTP/2 to Origin und Enhanced HTTP/2 Prioritization

HTTP/2, HTTP/2 to Origin und Enhanced HTTP/2 Prioritization zu aktivieren, ist ein No-Brainer. HTTP/2 ist ein riesiger Fortschritt gegenüber dem alten HTTP/1.1-Protokoll. HTTP/2 leistet einiges, aber das Wichtigste: Es beseitigt den alten Treppeneffekt, indem mehrere Dateien parallel über dieselbe Verbindung übertragen werden können. HTTP/2 gibt es seit 10 Jahren, und Browser wie Server unterstützen es flächendeckend!

Empfehlung: Alle drei aktivieren.

HTTP/3 (mit QUIC)

HTTP/3 mit QUIC ist dank Verbesserungen beim Verbindungsaufbau und der Latenz noch schneller als HTTP/2. HTTP/3 überträgt mehrere Streams unabhängig voneinander – selbst wenn einer davon verzögert wird. QUIC kombiniert Transport- und Verschlüsselungs-Handshakes, was die Verbindungszeit verkürzt. Das führt zu bis zu 10 % schnelleren TTFB-Zeiten! Laut dem Web Almanac 2025 unterstützen mittlerweile 38 % aller Websites HTTP/3.

Empfehlung: Aktivieren.

Brotli-Kompression

Brotli ist ein Kompressionsalgorithmus, der kleinere Dateien als Gzip erzeugt. Cloudflare aktiviert Brotli standardmäßig in allen Tarifen. Achte darauf, dass das so bleibt. Laut dem Web Almanac 2025 nutzen inzwischen 46 % aller über CDNs ausgelieferten Requests Brotli-Kompression.

Empfehlung: Aktiviert lassen (ist standardmäßig aktiv).

0-RTT Connection Resumption

0-RTT Connection Resumption beschleunigt sichere Verbindungen: Kehrt ein Nutzer auf deine Seite zurück, wird der anfängliche Handshake übersprungen. Dank zuvor gespeicherter Verschlüsselungsschlüssel können Daten sofort gesendet werden. Das reduziert die Latenz und verbessert die Ladezeit der Seite.

Empfehlung: Aktivieren.

Automatic Signed Exchanges (deprecated)

Über Signed Exchanges (SXGs) konnte die Google-Suche deine Inhalte vorab per Prefetch laden, ohne die Privatsphäre der Nutzer zu verletzen. SXGs konnten den LCP für Besucher aus den Google-Suchergebnissen um rund 450 ms verbessern.

Allerdings hat Cloudflare SXGs im Oktober 2025 eingestellt. Das Feature wurde entfernt und ist nicht mehr verfügbar. Falls du es aktiviert hattest, wurde es automatisch abgeschaltet. Speed Brain (Speculation Rules) ist der naheliegendste Ersatz für Prefetching – funktioniert allerdings nur bei Same-Site-Navigationen, nicht für Cross-Origin-Prefetching aus der Google-Suche wie damals SXGs.

Empfehlung: Diese Einstellung gibt es nicht mehr.

Scrape Shield

Scrape Shield soll die Inhalte auf deiner Website schützen. Auch wenn das nach einer guten Idee klingt: Ich rate von sämtlichen Scrape-Shield-Optionen strikt ab. Scrape Shield schleust JavaScript in deine Seite ein, um die zuvor verschleierten Inhalte wieder zu decodieren. Dieser Kompromiss aus Ladezeitverlust und Verstecken von Inhalten ist nicht sinnvoll: Echte Spammer lassen sich davon nicht täuschen, während echte Nutzer zusätzliche Skripte laden müssen, die die Seite ausbremsen.

Empfehlung: Deaktiviere Email Address Obfuscation und deaktiviere Hotlink Protection.

Bot Fight Mode und Super Bot Fight Mode

Das ist die mit Abstand schädlichste Cloudflare-Einstellung für deine Core Web Vitals. Wenn aktiviert, schleust Bot Fight Mode ein Skript namens invisible.js in jede Seite ein. Dieses Skript führt eine Browser-Challenge aus, die jeden Seitenaufruf um über 2.000 Millisekunden CPU-Ausführungszeit verlängert. Das sind 2 volle Sekunden, in denen der Main Thread blockiert ist, bevor deine Seite überhaupt interaktiv werden kann.

In der Praxis kann die Aktivierung des Bot Fight Mode deinen PageSpeed-Score um 20 Punkte oder mehr nach unten ziehen. Super Bot Fight Mode hat dasselbe Problem. Die Ironie dabei: Diese Modi sollen Bots abwehren, bestrafen am Ende aber jeden echten Nutzer, der deine Seite besucht.

Empfehlung: Deaktiviere sowohl Bot Fight Mode als auch Super Bot Fight Mode. Wenn du Bot-Schutz benötigst, nutze stattdessen WAF-Regeln von Cloudflare oder Rate Limiting. Diese injizieren kein clientseitiges JavaScript.

Caching > Konfiguration

Purge Cache

Das Leeren des Caches invalidiert sämtliche von Cloudflare zwischengespeicherten Dateien – einschließlich Stylesheets, JavaScript, Bildern und sogar Full-Page-Caches. Auch wenn das Leeren des Caches technisch gesehen keine dauerhafte Einstellung ist, muss ich vor einem Cache-Purge warnen: Deine Website wird dadurch spürbar langsamer, bis der Cache wieder aufgebaut ist!

Empfehlung: Vermeide es nach Möglichkeit, den gesamten Cache zu leeren. Bereinige nur betroffene Dateien!

Caching-Level

Das Caching-Level bestimmt, wie Cloudflare mit Query-Strings umgeht. Diese Einstellung solltest du dir genau ansehen.

Die „schnellste“ Option ist „Ignore query string“. Hierbei wird unabhängig vom Query-String immer dieselbe Ressource ausgeliefert. Das ist nur dann sinnvoll, wenn du dir zu 100 % sicher bist, dass auf deiner Website keine Query-Strings verwendet werden. Von Dritten angehängte Query-Strings werden dann einfach ignoriert.

„Standard“ liefert für jeden abweichenden Query-String eine eigene zwischengespeicherte Datei aus. Das ist die Standardeinstellung von Cloudflare. In Kombination mit Full-Page Edge Caching und Tracking-Parametern wie UTM-Parametern kann diese Einstellung jedoch zu Cache-Mismatches und einer niedrigeren Cache-Hit-Ratio führen! Ziehe in Erwägung, Tracking-Parameter mit Cloudflare Workers zu entfernen, um dieses Problem zu lösen.

Empfehlung: Wann immer möglich „Ignore query string“ wählen, andernfalls „Standard“. Vermeide die Option „No query string“.

Browser-Cache-TTL

Die Browser-Cache-TTL teilt dem Browser mit, wie lange er statische Ressourcen im Cache behalten darf. Zwischengespeicherte Ressourcen kann der Browser direkt lokal ausliefern. Sie stehen damit ungleich schneller bereit als über das Netzwerk. Eine kurze Browser-Cache-TTL entwertet den Browser-Cache ständig und drückt die Cache-Hit-Ratio. Stelle die Option auf „Respect Existing Headers“, damit der Cache-Control-Header deines Servers entscheidet: ein Jahr für statische Dateien mit Versionsangabe im Dateinamen. Ein festes Maximum an dieser Stelle überschreibt jede kürzere Gültigkeitsdauer, die dein Server bewusst setzt – und das Leeren des Cloudflare-Caches leert den Browser der Besucher nicht.

Empfehlung: „Respect Existing Headers“, zusammen mit Cache-Control: max-age=31536000 von deinem Server für statische Dateien mit Versionsnummer im Dateinamen.

Development Mode

Der Development Mode umgeht sämtliches Cloudflare-Caching, solange er aktiv ist. Beim Entwickeln mag die Versuchung groß sein, ihn einzuschalten. Tu das bitte nicht: Er deaktiviert das Caching auch für alle anderen Besucher. Richte dir stattdessen eine Development-Domain ein, auf der du entwickelst, oder schließe dich über Cache-Regeln selbst vom Cloudflare-Caching aus.

Empfehlung: Nicht aktivieren!

Caching > Tiered Cache

Tiered Cache reduziert die Anzahl der Anfragen an deinen Origin-Server und steigert die Cache-Hit-Ratio: Cloudflare sucht bei nicht zwischengespeicherten Dateien zuerst auf den eigenen Servern. Das entlastet deinen Backend-Server zusätzlich und setzt Ressourcen frei.

Empfehlung: Aktiviere Smart Tiered Caching Topology.

Über alle von CoreDash überwachten Websites hinweg zeigt sich: Seiten mit einem sauber konfigurierten CDN weisen beim p75 eine um 55 % schnellere TTFB auf als Seiten ohne CDN. Cloudflares Zusammenspiel aus HTTP/3, Brotli und Tiered Cache macht im Feld einen messbaren Unterschied. Nutze Real User Monitoring, um zu überprüfen, ob deine Cloudflare-Konfiguration für deine Nutzer tatsächlich greift.