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 Technology 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 Website Owner Finder 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 `<script>` tags is more reliable.
What Cloudflare free actually limits
Several owners I audited were not aware of what they were giving up by staying on free:
For most indie sites, the Pro plan ($25/mo) is overkill until you have either real WAF requirements or real bot traffic. The free plan is genuinely the right answer for the first $0-1M ARR.
When Cloudflare free is NOT the right answer
A few cases I see where Cloudflare free is the wrong choice and a site owner would benefit from alternatives:
1. Sites that must serve a video stream as static MP4. Cloudflare's free plan throttles large file responses to encourage Stream upsell. Use Bunny.net or Fastly for raw bandwidth.
2. APIs with high request volumes that need rate-limit configurability. Cloudflare's free rate limiting is basic; AWS API Gateway is purpose-built.
3. Sites whose origin is already on the edge (Vercel, Netlify, Cloudflare Pages itself). Adding another layer of Cloudflare in front is redundant and sometimes counterproductive (double caching, conflicting headers).
For the other 95% of indie web infrastructure, Cloudflare free is the answer. Just configure it.
The audit workflow in 15 minutes
For your own Cloudflare-fronted site:
1. Technology Detector — confirm Cloudflare is actually serving the URL. If not, your DNS is misconfigured.
2. SSL Certificate Checker — check the `cf-cache-status` header. Anything other than HIT/EXPIRED on cacheable URLs is leaving performance on the table.
3. Cloudflare dashboard → SSL/TLS → set to "Full (Strict)".
4. Dashboard → DNS → verify every public hostname is orange cloud (proxied).
5. Dashboard → Speed → Optimization → Brotli ON, Auto Minify OFF, Rocket Loader OFF, Early Hints ON.
15 minutes. Free. Most owners I do this for see measurably better LCP within 24 hours.
Methodology
The 100-site sample was a convenience sample, not random. It skews toward sites I help operate or audit professionally — meaning sites that are already at least moderately well configured. Real numbers on a random sample of all Cloudflare-fronted sites are probably worse.
I checked each site at one point in time over the past month. Cloudflare configurations can change; the snapshot may not reflect current state.
If you maintain a Cloudflare-fronted site and want me to add its (anonymised) configuration to the next audit, send the URL to info@krawly.io.