Cloudflare retired its Auto Minify feature on August 5, 2024, so the old toggle that stripped whitespace from your JavaScript, CSS, and HTML at the edge is gone. If you were relying on it, the honest news is that you lost almost nothing.
Cloudflare’s own data showed minification was trimming under 0.1% of page bytes across its network, so this is less a loss to recover from and more a nudge to put your effort where it actually counts: compression and caching, with minification handled in your build or caching layer.
Key Takeaways
- Cloudflare turned off Auto Minify on August 5, 2024; the toggle for JavaScript, CSS, and HTML is gone.
- It mattered far less than people assumed: across Cloudflare’s network the saving was under 0.1% of page bytes.
- The real speed levers are compression (Brotli or gzip) and caching, not minification.
- Minification belongs at build time or inside a caching plugin now, where you can test it and catch any breakage.
- If your pages felt faster with it on, turning on Brotli and proper caching will more than make up the difference.
What Cloudflare changed, and when
On August 5, 2024, Cloudflare removed Auto Minify from the dashboard under Speed, Optimization, and disabled it through the API too. The setting used to minify your HTML on the fly and minify CSS and JavaScript on cached files, all without you touching your code.
Existing sites simply had the option switched off; nothing in your origin files changed, and your pages kept serving exactly as before, just without the edge trimming a sliver of whitespace. Cloudflare laid out the reasoning in its deprecation announcement, and it is worth understanding before you go hunting for a replacement.
Why they dropped it
Two reasons, and both are honest. First, usage had been falling for years, because modern build pipelines (Vite, webpack, esbuild, and the rest) already minify assets at build time, so doing it again at the edge was redundant for most sites. Second, and this is the part worth sitting with, the benefit was tiny: Cloudflare measured the overall page-size reduction from Auto Minify at less than 0.1% across all the files it touched on its network.
There was also a quieter cost. Minifying HTML dynamically on every request can add a little processing delay, and Cloudflare found that delay sometimes outweighed the tiny saving. So this was not Cloudflare taking away a powerful tool; it was retiring something that had quietly stopped earning its keep.
Does losing it actually slow your site down?
For almost every site, no. Minification removes characters that compression was already going to squeeze anyway, so once Brotli or gzip is doing its job, the extra gain from stripping whitespace first is close to a rounding error. That is exactly why the network-wide number was so small.
If a page genuinely felt faster with Auto Minify on, the fix is not to recreate minification; it is to make sure the bigger levers are switched on. Compression and smart caching move far more weight than minification ever did, which is the same lesson that runs through real Core Web Vitals work, where render-blocking scripts and image weight matter, not a few saved bytes of whitespace.
Where minification belongs now
If you still want minified assets, and there is no harm in having them, do it closer to your code where you can see and test the result. On a build-based site that means your bundler handles it automatically at build time, which is the cleanest option because the minified files are what you ship and test.
On WordPress, a caching or optimization plugin (WP Rocket, LiteSpeed Cache, or the free Autoptimize) can minify and combine CSS and JavaScript for you, with the big advantage that you can preview the site and toggle it off the moment something breaks. That last point matters, because edge minification was notorious for occasionally mangling inline scripts with no easy way to debug it. If you run LiteSpeed, the same plugin that does this also handles your full-page caching; I cover how that fits together in the LiteSpeed Cache guide.
A simple replacement checklist
Rather than chasing the lost toggle, spend ten minutes on the things that genuinely move your load time:
- Confirm Brotli or gzip compression is on, because that is the lever Cloudflare itself points you to and it does far more than minification ever did.
- Make sure your static assets are cached at the edge with sensible TTLs, so repeat visitors are not re-downloading CSS and JavaScript at all.
- Move minification to your build step or a caching plugin, where you can test the output and roll it back instantly if a script breaks.
- Run a speed test (Cloudflare’s Observatory or PageSpeed Insights) before and after, so you are acting on measured numbers rather than a feeling.
If you are tuning performance at scale, the same priorities (compression, caching, and a lean asset pipeline) are what carry a site through heavy traffic, which I get into in the guide on whether WordPress can handle a million visitors.
So, do you need to replace Cloudflare Auto Minify?
No. There is no panicked replacement plan to run here, because the feature was doing so little that its absence is unlikely to show up in any real metric. If you do nothing at all, your site is essentially unchanged.
If you want to be thorough, make sure Brotli compression and edge caching are on, and let your build process or a caching plugin handle minification where you can actually test it. That setup is faster, safer, and more debuggable than the edge toggle ever was, which is probably why Cloudflare felt comfortable retiring it in the first place.
Update Logs
29 Jun 2026
- Updated now that the deprecation has happened: added Cloudflare’s own finding that Auto Minify saved under 0.1% of page bytes, and refocused the piece on compression, caching, and where to minify instead.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
