Cloudflare hat sein Automatische Minimierung Seit dem 5. August 2024 ist die alte Umschaltfunktion, die Leerzeichen am Anfang und Ende Ihrer JavaScript-, CSS- und HTML-Dateien entfernt hat, nicht mehr verfügbar. Falls Sie sich darauf verlassen haben: Ehrlich gesagt haben Sie dadurch so gut wie nichts verloren.
Cloudflares eigene Daten zeigten, dass die Minifizierung die Seitengröße im gesamten Netzwerk um weniger als 0,11 TP3T Byte reduzierte. Es handelt sich also weniger um einen Verlust, den es auszugleichen gilt, als vielmehr um einen Anstoß, Ihre Bemühungen dort zu konzentrieren, wo sie wirklich etwas bewirken: bei der Komprimierung und beim Caching, während die Minifizierung in Ihrer Build- oder Caching-Ebene abgewickelt wird.
Wichtigste Erkenntnisse
- Cloudflare hat „Auto Minify“ am 5. August 2024 deaktiviert; die Umschaltoption für JavaScript, CSS und HTML ist nicht mehr vorhanden.
- Das war weitaus weniger bedeutend, als man angenommen hatte: Im gesamten Cloudflare-Netzwerk betrug die Einsparung weniger als 0,1% Seitenbytes.
- Die eigentlichen Geschwindigkeitsfaktoren sind Komprimierung (Brotli oder gzip) und Caching, nicht die Minifizierung.
- Die Minifizierung sollte nun während der Erstellungsphase oder innerhalb eines Caching-Plugins erfolgen, wo man sie testen und eventuelle Fehler erkennen kann.
- Wenn sich Ihre Seiten bei aktivierter Funktion schneller anfühlten, werden die Aktivierung von Brotli und eine ordnungsgemäße Zwischenspeicherung diesen Unterschied mehr als ausgleichen.
Was Cloudflare geändert hat und wann
Am 5. August 2024 hat Cloudflare „Auto Minify“ aus dem Dashboard unter „Geschwindigkeit“ und „Optimierung“ entfernt und die Funktion auch über die API deaktiviert. Mit dieser Einstellung wurden Ihr HTML-Code in Echtzeit sowie CSS- und JavaScript-Dateien im Cache minimiert, ohne dass Sie Ihren Code selbst bearbeiten mussten.
Bei bestehenden Websites wurde diese Option lediglich deaktiviert; an Ihren Quelldateien hat sich nichts geändert, und Ihre Seiten wurden weiterhin genau wie zuvor bereitgestellt – nur ohne, dass am Rand ein kleiner Teil des Leerraums abgeschnitten wurde. Cloudflare hat die Gründe dafür in seinem Ankündigung der Auslaufphase, und es lohnt sich, dies zu verstehen, bevor Sie sich auf die Suche nach einem Ersatz machen.
Warum sie es fallen gelassen haben
Dafür gibt es zwei Gründe, und beide sind ehrlich gemeint. Erstens war die Nutzung seit Jahren rückläufig, da moderne Build-Pipelines (Vite, Webpack, Esbuild und die anderen) die Assets bereits während des Build-Vorgangs minimieren, sodass eine erneute Minimierung am Edge für die meisten Websites überflüssig war. Zweitens – und das ist der Punkt, über den man einmal nachdenken sollte – war der Nutzen verschwindend gering: Cloudflare hat die durch „Auto Minify“ erzielte Reduzierung der Gesamtseitengröße auf weniger als 0,11 TP3T in allen Dateien, auf die es im Netzwerk zugegriffen hat.
Es gab aber auch einen weniger offensichtlichen Nachteil. Die dynamische Minifizierung von HTML bei jeder Anfrage kann zu einer leichten Verzögerung bei der Verarbeitung führen, und Cloudflare stellte fest, dass diese Verzögerung den geringen Zeitgewinn manchmal überstieg. Es ging also nicht darum, dass Cloudflare ein leistungsstarkes Tool abgeschafft hat, sondern darum, etwas aus dem Verkehr zu ziehen, das sich still und leise nicht mehr bezahlt gemacht hatte.
Verlangsamt das Fehlen dieser Funktion Ihre Website tatsächlich?
Bei fast jeder Website ist das nicht der Fall. Bei der Minifizierung werden Zeichen entfernt, die durch die Komprimierung ohnehin bereits reduziert worden wären. Sobald also Brotli oder gzip ihre Arbeit verrichten, ist der zusätzliche Gewinn durch das vorherige Entfernen von Leerzeichen fast schon vernachlässigbar. Genau aus diesem Grund war der netzwerkweite Wert so gering.
Wenn sich eine Seite bei aktivierter „Auto Minify“-Funktion tatsächlich schneller anfühlt, besteht die Lösung nicht darin, die Minifizierung neu zu implementieren, sondern sicherzustellen, dass die wichtigeren Hebel aktiviert sind. Komprimierung und intelligentes Caching haben einen weitaus größeren Einfluss als die Minifizierung jemals hatte – dieselbe Erkenntnis zieht sich durch echte Core Web Vitals im Einsatz, wo es auf rendernblockierende Skripte und die Dateigröße von Bildern ankommt – und nicht auf ein paar eingesparte Bytes an Leerzeichen.
Wo die Minifizierung heute hingehört
Wenn Sie dennoch minifizierte Dateien wünschen – was ja keinen Nachteil mit sich bringt –, sollten Sie dies näher an Ihrem Code tun, wo Sie das Ergebnis sehen und testen können. Bei einer auf Builds basierenden Website bedeutet dies, dass Ihr Bundler dies automatisch während des Build-Vorgangs übernimmt. Das ist die sauberste Lösung, da Sie die minifizierten Dateien schließlich ausliefern und testen.
In WordPress kann ein Caching- oder Optimierungs-Plugin (WP Rocket, LiteSpeed Cache oder das kostenlose Autoptimize) CSS und JavaScript für Sie minimieren und zusammenfassen – mit dem großen Vorteil, dass Sie eine Vorschau der Website anzeigen und die Funktion sofort deaktivieren können, sobald etwas nicht mehr funktioniert. Dieser letzte Punkt ist wichtig, da die Edge-Minimierung dafür bekannt war, Inline-Skripte gelegentlich zu verfälschen, ohne dass es eine einfache Möglichkeit gab, dies zu beheben. Wenn Sie LiteSpeed nutzen, übernimmt dasselbe Plugin, das dies erledigt, auch Ihr Vollseiten-Caching; wie das zusammenpasst, erkläre ich im Anleitung zu LiteSpeed Cache.
Eine einfache Checkliste für den Austausch
Anstatt dem verlorenen Schalter hinterherzujagen, widmen Sie lieber zehn Minuten den Dingen, die Ihre Ladezeit wirklich beeinflussen:
- Bestätigen Brotli- oder gzip-Komprimierung ist aktiviert, denn das ist die Option, auf die Cloudflare selbst hinweist, und sie leistet weitaus mehr, als die Minifizierung jemals geleistet hat.
- Stellen Sie sicher, dass Ihr Statische Ressourcen werden zwischengespeichert am Serverrand mit sinnvollen TTL-Werten, sodass wiederkehrende Besucher CSS- und JavaScript-Dateien gar nicht erst erneut herunterladen müssen.
- Verschieben Minifizierung in Ihren Build-Schritt oder ein Caching-Plugin integrieren, wo Sie die Ausgabe testen und sofort zurücksetzen können, falls ein Skript nicht funktioniert.
- Führen Sie einen Geschwindigkeitstest durch (von Cloudflare) Beobachtungsstelle (oder PageSpeed Insights) vor und nach der Optimierung, damit Sie sich auf gemessene Werte stützen und nicht auf Ihr Bauchgefühl.
Wenn Sie die Leistung im großen Maßstab optimieren, sind es dieselben Prioritäten (Komprimierung, Caching und eine schlanke Asset-Pipeline), die eine Website auch bei hohem Datenverkehr stabil halten – darauf gehe ich im Leitfaden zum Thema „Ob …“ näher ein. WordPress kann eine Million Besucher bewältigen.
Müssen Sie also „Cloudflare Auto Minify“ ersetzen?
Nein. Es gibt keinen Notfallplan für eine Ersatzlösung, da diese Funktion so wenig geleistet hat, dass ihr Fehlen sich wahrscheinlich in keiner konkreten Kennzahl bemerkbar machen wird. Wenn Sie gar nichts unternehmen, bleibt Ihre Website im Wesentlichen unverändert.
Wenn Sie gründlich vorgehen möchten, stellen Sie sicher, dass die Brotli-Komprimierung und das Edge-Caching aktiviert sind, und überlassen Sie die Minifizierung Ihrem Build-Prozess oder einem Caching-Plugin, wo Sie sie tatsächlich testen können. Diese Konfiguration ist schneller, sicherer und lässt sich besser debuggen als der Edge-Schalter es jemals war – was wahrscheinlich auch der Grund dafür ist, dass Cloudflare keine Bedenken hatte, ihn überhaupt abzuschaffen.
Änderungsprotokolle
29. Juni 2026
- Aktualisiert nach der offiziellen Abkündigung: Es wurde die von Cloudflare selbst gewonnene Erkenntnis hinzugefügt, dass „Auto Minify“ weniger als 0,11 TP3T an Seitenbytes eingespart hat, und der Schwerpunkt des Artikels wurde stattdessen auf Komprimierung, Caching und die Frage verlagert, wo eine Minifizierung sinnvoll ist.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
