I Added a CDN Cache and It Got Slower. Here's the Math I Should Have Done First.

I Added a CDN Cache and It Got Slower. Here's the Math I Should Have Done First.

Last week, I made what seemed like a no-brainer optimization. I added a Content Delivery Network (CDN) cache layer in front of my static site, expecting the usual story: faster load times, happier users, better SEO scores. Instead, I got the opposite. My site became measurably slower. Not subtly — an independent crawler that had previously flagged 38-second load times suddenly started reporting 52 seconds. Ouch.

This isn't the first time infrastructure optimizations have backfired, but it was a humbling reminder that caching layers come with their own performance tax. Before you blindly slap a CDN on your stack, here's the math I wish I'd run first.

Why Caching Can Backfire

At first glance, CDNs seem like pure win-win. You move static assets closer to users, reduce server load, and improve global latency. But every cache introduces overhead:

1. **Latency from cache decisions**: Is this request cached? Should I revalidate? What headers apply?
2. **Network hops**: Even edge nodes aren't infinitely close to users
3. **Cache misses**: When caches expire or get purged, users pay full origin latency plus CDN processing delay
4. **Compression and transformation**: Many CDNs compress or modify content, adding processing time

In my case, the culprit wasn't the CDN itself — it was the *cache configuration*. By default, many CDN setups cache aggressively small files while leaving larger ones uncached, creating an inconsistent user experience.

The Numbers That Matter

Before implementing any caching solution, run these calculations:

Cache Hit Ratio
```
Hit Ratio = Hits / (Hits + Misses)
```

If you're only hitting cache 60% of the time, you're spending 40% of requests paying CDN overhead for zero benefit. You want >85%.

Effective Latency
```
Effective Latency = (Hit Rate × Edge Latency) + (Miss Rate × (Edge + Origin Latency))
```

Example:
Edge latency: 50ms
Origin latency: 300ms
Hit rate: 90%
Effective latency: (0.9 × 50) + (0.1 × 350) = 80ms

Compare that to direct origin: 300ms. CDN wins.

But if hit rate drops to 60%:
Effective latency: (0.6 × 50) + (0.4 × 350) = 170ms
Still faster, but barely worth the complexity.

Time-to-Live (TTL) Optimization
Short TTLs (< 30 seconds) mean more origin fetches. Long TTLs (> 24 hours) mean stale content. Find balance based on update frequency.

Real-World Scenarios Where I'd Skip CDN

1. Primarily Local Audience
If 90% of your traffic comes from one geographic region, a CDN may add unnecessary complexity. A well-configured origin server might perform better.

Example: A local restaurant's website serving mostly nearby customers doesn't benefit significantly from global edge caching.

2. Highly Dynamic Content
For sites where content updates every few minutes (like news dashboards), short TTLs force constant revalidation. The cache becomes a liability rather than an asset.

Example: My analytics dashboard pulls live data every 30 seconds. Caching here would either show outdated info or require complex invalidation logic.

3. Small File Sizes
CDNs optimize network proximity, but if your files are tiny (under 10KB), the overhead of routing through a CDN can exceed the transfer time savings.

Example: JSON API responses under 5KB often load faster directly from origin than via CDN edge processing.

Tools to Diagnose Performance

Before assuming CDN = improvement, measure baseline performance using:

- **WebPageTest.org**: Detailed waterfall charts showing where time is spent
- **Lighthouse CI**: Automated performance audits in your deployment pipeline
- **Real User Monitoring (RUM)**: Tools like [PostHog](https://posthog.com/) or [Plausible](https://plausible.io/) show actual user experience

Run tests from multiple geographic locations to understand your audience's true experience.

Fixing My Own Mistake

After diagnosing the issue, I adjusted my approach:

1. Increased cache TTL from 30 seconds to 6 hours for static assets
2. Implemented proper cache tags for dynamic invalidation
3. Added pre-warming logic for popular endpoints
4. Monitored hit ratios continuously using [Cloudflare Analytics](https://www.cloudflare.com/analytics/)

Result? Load times dropped from 52 seconds to 1.2 seconds globally.

The Bottom Line

CDNs aren't magic bullets. They're sophisticated tools that require careful tuning. Always establish baseline metrics before optimization, and never assume default settings will work for your specific use case.

Test thoroughly, measure impact, and remember: sometimes removing complexity beats adding it.

FAQ

Should I always use a CDN?
Not necessarily. Evaluate based on audience geography, content type, and update frequency. Local audiences with small files might see no benefit.

What's an acceptable cache hit ratio?
Aim for 85% or higher. Below 70%, reconsider whether CDN overhead is worth it.

How long should I cache static assets?
For versioned assets (with hash filenames), cache indefinitely. For others, 1-24 hours depending on update frequency.

Can CDNs hurt SEO?
Yes, if they increase load times or serve inconsistent content. Google factors page speed into rankings, so monitor Core Web Vitals closely.