Most sites proxy through Cloudflare for DDoS protection and basic caching but leave the speed settings at their defaults. That misses half the point. A few toggles in the dashboard can drop time to first byte by hundreds of milliseconds and shrink HTML payloads by a third.
I've walked clients through these six settings dozens of times in support tickets. They work for everything from a five-page brochure site to a WordPress blog pulling a million hits a month. You don't need Cloudflare's paid tiers for most of them, and the ones that do cost money offer free trials so you can benchmark before committing.
Auto Minify for HTML, CSS, and JavaScript
Cloudflare strips whitespace, comments, and line breaks from HTML, CSS, and JS files before sending them to the browser. The savings add up fast on pages with inline styles or verbose templates.
Go to Speed > Optimization and tick the boxes for Auto Minify. All three. The edge servers cache the minified version, so your origin never sees the extra CPU load.
One caveat: if your build pipeline already minifies assets, you might see duplicate processing or broken sourcemaps. Check your browser console after enabling it. If you spot errors, turn off the relevant file type and leave the rest enabled. In practice, most CMSs and static site generators play nicely with Cloudflare's minifier because it's conservative and doesn't rewrite code—just removes the fluff.
Brotli Compression
Brotli beats Gzip on compression ratio for text files—HTML, JSON, CSS, JavaScript, SVG. Cloudflare compresses responses at the edge when the client sends an Accept-Encoding: br header, which every modern browser does.
The setting lives under Speed > Optimization and is usually on by default, but I've seen it mysteriously toggled off on older zones. Confirm it shows Enabled. If your origin already Brotli-compresses responses and sets the Content-Encoding header, Cloudflare passes them through unchanged, so there's no double-compression risk.
To verify it's working, open your browser's network panel and inspect the response headers for an HTML document. You should see content-encoding: br. If you see gzip or nothing, the client might not support Brotli (unlikely) or Cloudflare didn't compress the response (check the setting again and purge the cache).
Early Hints (HTTP 103)
Early Hints sends a preliminary HTTP 103 response with Link headers that tell the browser to preload or preconnect to critical resources while the origin is still generating the full page. The browser starts fetching CSS, fonts, and scripts in parallel instead of waiting for the HTML to arrive.
Navigate to Speed > Optimization > Early Hints and toggle it on. Cloudflare automatically generates hints for resources referenced in <link rel="preload"> or <link rel="preconnect"> tags in your HTML, so you don't have to configure headers manually. If your pages already include those tags, Early Hints amplifies their effect. If they don't, add them to your template for fonts and above-the-fold CSS, then let Cloudflare do the rest.
The performance win is most visible on high-latency connections—mobile users on 4G or desktop users far from your origin. TTFB stays the same, but perceived load time drops because rendering starts sooner.
Argo Smart Routing
Argo routes requests across Cloudflare's private backbone instead of the public internet. For sites whose origin is geographically distant from a large chunk of their audience, Argo can shave 30-50% off origin round-trip time. It's a paid feature—billed per gigabyte of traffic—but the first gigabyte each month is heavily discounted, and you can disable it anytime.
Go to Traffic > Argo and click Enable. Cloudflare measures performance for a week, then shows you the average improvement in the dashboard. If the speed gain justifies the cost, leave it on. If not, turn it off.
I've found Argo most effective for sites with origins in a single region (like a VPS in Frankfurt serving global traffic) and less impactful when the origin already sits behind a multi-region setup or another CDN layer. Test it yourself rather than trusting benchmarks from other sites—network topology varies wildly.
Mirage and Polish (Image Optimization)
Mirage lazy-loads images and serves low-resolution placeholders on slow connections. Polish strips metadata, converts images to WebP or AVIF where the browser supports it, and applies lossless or lossy compression. Both require a Pro plan or higher, but they're worth the upgrade if images make up the bulk of your page weight.
Enable Mirage under Speed > Optimization > Mirage. For Polish, go to Speed > Optimization > Polish and choose Lossless (safe for all image types) or Lossy (better compression, minimal quality loss). If you want WebP conversion, tick WebP.
Polish respects your origin's Cache-Control headers, so if you've set no-transform, Cloudflare won't touch the image. Mirage works transparently—no code changes needed—but if your site already lazy-loads images with JavaScript, the two systems can conflict. Disable one or the other and compare page load times.
Caching Level and Browser Cache TTL
Cloudflare's default caching level is Standard, which caches static files (images, CSS, JS) but not HTML. Bumping it to Ignore Query String tells Cloudflare to serve the same cached asset regardless of query parameters, which helps when marketing tags or session IDs pollute URLs. Be careful with this if your app uses query strings to serve different content—it can break search or pagination.
Find the setting under Caching > Configuration > Caching Level. For most WordPress sites or static HTML, Ignore Query String is safe and speeds up repeat visits.
Browser Cache TTL controls the Cache-Control header Cloudflare sends to the browser. The default is four hours. I usually bump it to one day for static assets that don't change often, or one week for versioned files (like style.v2.css). Go to Caching > Configuration > Browser Cache TTL and pick a value that matches your release cadence. Longer TTLs mean fewer requests, but users won't see updates until the cache expires or you purge it.
To cache HTML at the edge, create a Page Rule with Cache Level: Cache Everything for your entire site or specific paths. Add an Edge Cache TTL to control how long Cloudflare holds the HTML before revalidating with the origin. This works well for blogs and marketing pages that don't personalize content per user. For dynamic apps, stick with Standard caching or use Workers to cache selectively.
What about Rocket Loader?
Rocket Loader defers JavaScript execution by bundling and asynchronously loading all scripts. In theory, it speeds up rendering. In practice, it breaks a lot of sites—especially those relying on inline scripts or third-party widgets that expect synchronous execution.
I leave it off by default and only enable it if the site has minimal JS dependencies and someone is willing to test every interactive element afterward. If you want to try it, go to Speed > Optimization > Rocket Loader, turn it on, and thoroughly check forms, modals, analytics, and any AJAX features. At the first sign of trouble, turn it back off.
Purging Cache After Enabling Settings
After toggling any of these, purge your cache under Caching > Configuration > Purge Everything. Cloudflare won't re-compress or re-minify assets that are already cached, so you need to force a refresh to see the new behavior. Wait a minute, then load your site in an incognito window and inspect the network tab to confirm the changes took effect.
Start with the free settings first
Enable Auto Minify, Brotli, and Early Hints today—they're free, low-risk, and compatible with almost every site. Measure your TTFB and page load time with tools like WebPageTest or GTmetrix before and after, so you can see the real-world impact. If those three settings deliver meaningful improvements, consider adding Argo or upgrading to Pro for image optimization. Not every site needs every setting, but leaving them all off is leaving speed on the table.