Marcell CD

The power of CDNs

You know the feeling. Your app flies on localhost. It’s snappy when your colleague tests it from the next desk over. But then users from the other side of the world start complaining about slow load times. You’ve done everything right—optimized your database queries, compressed your assets, even enabled HTTP/2. So what gives?

Here’s the thing: at some point, you’re not fighting bad code anymore. You’re fighting the speed of light.

This is where Content Delivery Networks (CDNs) come in. They’re your secret weapon against physics itself. Let me show you how they work, what to put on them, and how to avoid the common mistakes that can turn your performance solution into a debugging nightmare.

The Big Idea: Copy Your Stuff Everywhere

Picture this: Your server lives in a data center in Frankfurt. A user in Singapore wants to load your app. That’s about 10,000 kilometers of cables, routers, and network hops. Every. Single. Request.

A CDN solves this by putting copies of your content in data centers around the world. These are called edge servers or Points of Presence (PoPs). Now when that Singapore user visits your site, they get content from a server in Singapore, not Frankfurt.

Here’s what happens behind the scenes:

  1. User types in your website URL
  2. DNS says “Hey, talk to the CDN instead”
  3. CDN figures out which edge server is closest
  4. That edge server either:
    • Has your content ready to go (cache hit—fast!)
    • Needs to fetch it from your origin server first (cache miss—slower, but only happens once)

The beautiful part? Once one user in a region requests something, everyone else nearby gets the cached version. Distance shrinks. Speed goes up. Users happy.

What Should Live on Your CDN?

Not everything belongs on a CDN. Think of it like packing for a trip—you want to bring the essentials, not your entire house.

Perfect for CDNs:

Keep these off your CDN cache:

You can still route these through your CDN for other benefits (like better security), but don’t cache them. The CDN will just pass them through to your origin server.

Cache-Control: Teaching Your CDN What to Do

The Cache-Control header is how you tell CDNs (and browsers) how to handle your content. Think of it as writing instructions on a storage box. Here are the patterns that actually matter:

Quick but important detail: shared caches (CDNs) and browsers can use different TTLs.

Cache-Control: public, max-age=60, s-maxage=300

Translation: “Browsers cache for 60 seconds, but CDNs can cache for 5 minutes.”

This is useful when you want faster repeat views for end users, while still reducing origin load globally.

For Static Assets (The “Set It and Forget It” Approach)

When you control the deployment and can change filenames:

Cache-Control: public, max-age=31536000, immutable

Translation: “Cache this for a year. It’s never changing.”

Use this with versioned filenames like:

When you deploy updates, the filename changes, so the CDN treats it as completely new content. No cache busting needed!

For Content That Changes Sometimes

For homepages, product listings, or “trending” pages:

Cache-Control: public, max-age=60

Translation: “Cache this for 60 seconds, then check if it’s still fresh.”

This absorbs traffic spikes while keeping content reasonably up-to-date. You can also add these headers to enable smart revalidation:

ETag: "version-123"
Last-Modified: Mon, 13 Apr 2026 10:00:00 GMT

Now the CDN can ask “Has this changed?” instead of downloading everything again.

For Personal or Sensitive Content

Cache-Control: private, no-store

Translation: “This is for one person’s eyes only. Don’t save it anywhere.”

This prevents the nightmare scenario where User A sees User B’s bank balance because of aggressive caching.

If the response depends on headers like Authorization, language, or device type, set Vary correctly so caches don’t mix responses between different request contexts:

Vary: Authorization, Accept-Language

Use Vary sparingly. Too many dimensions can hurt cache hit rates.

For Graceful Failures

Some CDNs support these handy extensions:

Cache-Control: public, max-age=60, stale-while-revalidate=300, stale-if-error=600

Translation:

This keeps your site running even when things go wrong.

Invalidation: Your Safety Valve

Even with good cache headers, you’ll eventually need to force updates quickly.

Full-cache purges are tempting, but they usually create a thundering herd against your origin. Be surgical when you invalidate.

The Hidden Benefits You’ll Love

Sure, CDNs make things faster. But that’s just the beginning:

Your Origin Server Gets a Break

Instead of serving the same logo.png file 10,000 times, your server handles it once. The CDN does the rest. This means your server can focus on the important stuff—like processing orders or running complex queries.

Built-in DDoS Protection

CDNs are built to handle massive traffic. When someone tries to take down your site with a flood of requests, the CDN absorbs it like a sponge. Your origin stays safe behind the scenes.

Free Performance Upgrades

Most CDNs automatically:

You get all these optimizations without touching your code.

Common Mistakes (And How to Avoid Them)

The “Broken Deploy” Trap

Here’s how to ruin your Friday afternoon:

  1. Use long cache times
  2. Don’t version your filenames
  3. Deploy new code
  4. Try to purge the entire CDN cache

Result: Some users get new HTML that asks for old JavaScript. Nothing works. Support tickets everywhere.

The fix: Always version your static assets. Cache them forever. Let the filename changes handle cache invalidation.

The “Cache Key Explosion” Problem

If your app adds random query parameters (?timestamp=1234567890), you’re creating a new cache entry every time. Your cache hit rate plummets.

The fix: Configure your CDN to ignore irrelevant query parameters. Only include parameters that actually change the content.

The “Backdoor to Origin” Security Hole

If people can still hit your origin server directly, they can bypass all your CDN’s security features.

The fix: Configure your origin to only accept requests from your CDN’s IP addresses. Make the CDN the only way in.

Your CDN Strategy in Five Steps

  1. Start with static assets: Put all your JS, CSS, and images behind the CDN with aggressive caching and versioned filenames.

  2. Find cacheable APIs: Look for public, read-heavy endpoints that can handle being a few seconds out of date.

  3. Protect personal data: Mark user-specific responses with private, no-store.

  4. Lock down your origin: Only allow CDN traffic to reach your servers.

  5. Monitor what matters: Track cache hit rates, response times by region, and origin server load.

The Mental Model That Sticks

Think of it this way:

Your job is to figure out what can be photocopied (cached) and what needs to come from the source every time. Once you start thinking this way, CDNs stop being mysterious and become just another tool in your performance toolkit.

Remember: CDNs don’t make slow code fast. They make fast code available everywhere. Get your app running well locally first, then let the CDN spread that performance around the globe.