Why "free Cloudflare" deserves an honest audit
Cloudflare's free tier is the most common piece of web infrastructure on the indie internet in 2026. It is genuinely good — global anycast network, free SSL, basic DDoS protection, unlimited bandwidth. Most sites benefit from turning it on.
But "free" is not "configured well". Across 100 small-to-mid market sites I audited over the past month — all running Cloudflare's free tier — three patterns kept appearing. None are Cloudflare's fault. All cost the site owner real performance or real money downstream.
This is the field report. Cloudflare is still my default recommendation. The defaults are not.
How I built the sample
100 production sites running Cloudflare free. Mix of WordPress (40), Next.js / static (25), Shopify storefronts via custom domains (15), and custom backends (20). Sites were drawn from clients, agency partners, and a random sample I confirmed were on the free plan via CDN Detector (which reads response headers like `cf-ray`, `server: cloudflare`, and the `__cf_bm` cookie that only appears on free plans during challenge issuance).
For each site I checked:
Pattern 1: 60% of sites had cache hit ratio under 50%
The single most common issue. Most owners think "I'm on Cloudflare" means content is cached at edge. It doesn't, by default. Cloudflare's free tier caches static assets (images, CSS, JS) but not HTML by default.
For most sites, that's fine. But for sites whose HTML is mostly static (blog posts, marketing pages, anything that doesn't change per visitor), the default leaves performance on the table. Every request for the same blog post hits the origin server.
The check: load any blog post on the site, then check the response headers for `cf-cache-status`. Common values:
If you're seeing `MISS` on the same blog post URL twice in a row, your HTML is not being cached at edge even though it could be.
The fix on the free tier: Cloudflare's "Cache Everything" page rule (the free tier gets 3 page rules). One rule that matches `example.com/blog/*` with "Cache Level: Cache Everything" and "Edge Cache TTL: 1 month" turns a 100ms origin fetch into a 5ms edge hit globally. For most blogs, the cache invalidates fast enough through manual purges or webhook integration.
Pattern 2: 40% of sites running "Full" SSL instead of "Full (Strict)"
Cloudflare's SSL options:
A staggering 40% of my sample was running "Full" not "Full Strict". Most owners set "Full" once during initial migration when their origin had a self-signed cert, then never re-tightened after switching to a real cert.
Why it matters: an attacker with network access between Cloudflare's edge and your origin (cloud provider misconfigurations happen) can intercept traffic on "Full". On "Full Strict" they cannot.
The fix: SSL/TLS → Overview → set to "Full (strict)". Free, instant, and only breaks if your origin really doesn't have a valid cert (in which case fix that first — Let's Encrypt is free).
Pattern 3: DNS records exposed beyond the proxy
15% of sites had DNS records (A records, sometimes the apex) set to "DNS only" mode (the grey cloud) instead of "Proxied" (the orange cloud). Owners had set them up like this either accidentally or because they didn't realise the implications.
When a record is "DNS only", Cloudflare resolves the name but does not proxy traffic. That means:
When you set up Cloudflare, the dashboard makes both options look similar. The orange/grey cloud icon is the only difference, and beginners often don't notice it.
I use DNS Record Checker to verify which records are proxied. Proxied records resolve to Cloudflare's edge IPs (104.16.x.x, 172.67.x.x, etc.). DNS-only records resolve to your origin's real IP.
For every public hostname, ask: does this hostname need to be proxied? If yes, orange cloud. If no (a mail subdomain, an internal admin record), grey is fine but consider whether the subdomain should even exist publicly.
Smaller issues that show up
`Brotli` compression is off
15% of sites had `Speed → Brotli` set to off (the default for some older accounts). Brotli compresses HTML better than gzip by about 15-20% on average. Free to enable, no downside.
`Auto Minify` is on (turn it off)
Conversely, 35% had Auto Minify enabled — Cloudflare strips whitespace and comments from HTML/JS/CSS at the edge. This was a popular optimization in 2018. In 2026 it breaks more than it helps:
Disable Auto Minify. Let your build pipeline handle it. The "performance" gains are negligible on modern, build-pipeline-minified code.
"Rocket Loader" is on
The most aggressive Cloudflare default. Rocket Loader rewrites all your JS to defer and load asynchronously. In 2024 it broke 1 in 4 sites I audited; in 2026 it's better but still breaks site-specific event handlers about 1 in 12 sites.
Recommendation: leave it OFF unless you have explicit reason to enable it. Modern `async`/`defer` on `