CDN cache hit ratios commonly reach 80% to 95%, and CDNs can absorb 70% or more of origin server requests (AWS). That sounds great. But if you’re chasing that number, you might be optimizing the wrong thing. Here’s the truth: cache hit ratio is a vanity metric. What matters is whether you’re serving the right content, and that’s controlled by Cache-Control headers, not by eviction policies or CDN defaults.
Is a high cache hit ratio always good?
No. A high hit ratio can mask problems. If you’re caching dynamic content with a long TTL, you might serve stale data and still have a 95% hit ratio. That’s not a win; that’s a bug. The number doesn’t tell you if your users are seeing fresh content. It just tells you how often you’re avoiding the origin. But if the origin would have returned something different, you’ve traded correctness for speed.
Doesn't a CDN automatically cache everything?
No. CDNs have default behaviors, but they’re not magic. Cloudflare, for example, by default caches certain HTTP status codes when no cache-control/expires headers are present: 200/206/301 for 120 minutes, 302/303 for 20 minutes, 404/410 for 3 minutes; all other status codes are not cached by default (Cloudflare). So, if you’re not setting headers, you’re at the mercy of these defaults. That’s a recipe for serving stale content or caching things you shouldn’t.
Is eviction policy the key to cache performance?
Eviction policy is about what happens when your cache is full. It’s important, but it’s not the first thing to tune. Redis, for instance, defaults to LRU eviction, and AWS recommends allkeys-lru because a cache is not storage (AWS). But eviction doesn’t decide what gets stored in the first place. That’s your headers’ job. If you’re storing the wrong things, eviction is just shuffling deck chairs.
Isn't cache invalidation just about purging?
Purging is the brute-force approach. Cloudflare’s purge by single-file instantly removes a cached resource across all data centers, so the next request gets the latest version (Cloudflare). That works, but it’s reactive. You shouldn’t rely on purging to fix your cache. Instead, use validators like ETags and Last-Modified to do conditional revalidation. ETag is an identifier for a specific version of a resource, and when content hasn’t changed, the server doesn’t need to resend the full response (MDN). That’s efficient and precise.
Are CDN cache limits a big deal?
They can be. Cloudflare’s cacheable file limits: Free/Pro/Business customers have a 512 MB limit; the Enterprise default maximum cacheable file size is 5 GB (Cloudflare). If you’re serving large files, you might hit that wall. But again, that’s a size limit, not a freshness limit. You can have a 5 GB file cached forever if you set a long max-age. That’s a choice.
So, what should I do first?
Stop fiddling with eviction policies and CDN settings. Set proper Cache-Control headers on your responses. Use max-age for static content, no-cache for content that needs revalidation, and no-store for sensitive dynamic content. That’s your first line of defense. And don’t forget the Vary header when you’re doing content negotiation, because it defines the cache key (MDN).
Is there a case where eviction matters more?
Only when you’ve already got your headers right and you’re still running out of memory. Then, yes, you need a good eviction policy. But that’s a secondary concern. The primary concern is always: what are you caching, and for how long?
Takeaway
Cache hit ratio is a vanity metric. Focus on Cache-Control headers first. They control freshness, which is what actually matters. Eviction and CDN settings are secondary. Get the headers right, and the hit ratio will follow.
Sources
- AWS - https://aws.amazon.com/caching/
- Cloudflare - https://developers.cloudflare.com/cache/concepts/default-cache-behavior/
- Cloudflare - https://developers.cloudflare.com/cache/how-to/purge-cache/purge-by-single-file/
- MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
- MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary
- Redis - https://redis.io/docs/latest/develop/reference/eviction/
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!