Your server is in one city. Your users are everywhere else. Every image, script and stylesheet has to cross that distance, and no amount of code optimisation can make light travel faster through a cable under the ocean.

A Content Delivery Network doesn't try. It moves copies of your files closer to the people asking for them. It's one of the cheapest, biggest speed-ups a website can get, and also one of the easiest ways to accidentally show one user another user's page. Let's look at both sides.

The idea: a warehouse in every neighbourhood

Imagine an online shop with one warehouse. Every order, from anywhere, ships from there. Now imagine small local depots stocked with the most popular items. Most orders arrive the next morning from down the road, and only unusual items come from the main warehouse.

A CDN is that network of depots. They're called edge locations (or points of presence), spread around the world. Your own server is the origin, the main warehouse.

One request, step by step

1. A user in Doha opens your site. DNS for cdn.example.com (or your whole domain) points to the CDN, which routes them to a nearby edge location.
2. The browser asks that edge for /build/app-4f9a1c.js.
3. Cache hit: the edge already has it and returns it immediately. Your origin never hears about the request.
4. Cache miss: the edge fetches the file from your origin, returns it to the user, and keeps a copy for the next person nearby, for as long as your cache rules allow.

The speed comes from three places. Shorter distance for the data itself. The secure connection being set up with a nearby edge instead of a faraway server, which matters because a TLS handshake takes several round trips. And your origin doing far less work, because most requests never reach it.

Your headers are the instructions

A CDN mostly does what your Cache-Control headers tell it to. Get these right and most of the work is done:

# Fingerprinted assets (app-4f9a1c.js): cache "forever"
Cache-Control: public, max-age=31536000, immutable

# HTML pages: always check with the server first
Cache-Control: no-cache

# A public API response that's the same for everyone
Cache-Control: public, s-maxage=60, stale-while-revalidate=30

# Anything personal
Cache-Control: private, no-store

• max-age applies to browsers and CDNs; s-maxage applies only to shared caches like the CDN, so you can cache longer at the edge than in the browser.
• no-cache doesn't mean "don't cache". It means "cache, but check it's still fresh before using it". no-store is the real "never keep this".
• stale-while-revalidate lets the cache serve a slightly old copy instantly while fetching a fresh one in the background.

In Laravel, the cache.headers middleware sets these for a route: Route::get('/api/listings', ListingIndexController::class)->middleware('cache.headers:public;max_age=300;etag').

What to put on a CDN

Invalidation: the hard part, made easy

"There are only two hard things in computer science: cache invalidation and naming things." With a CDN, you can mostly avoid the first one.

The trick is fingerprinted file names. Laravel's Vite setup already does this: build output goes to public/build with a content hash in every name, and @vite writes the right names into your HTML. A new deploy means new names, so there's nothing old to invalidate. The old files just stop being requested.

For things that keep the same URL (an uploaded image someone replaced, an HTML page), you either use short cache times or purge the path through the CDN's API or dashboard. Purges work, but they take a moment to spread across all edges and some providers limit or charge for them, so they're a tool, not a strategy.

Images: the quiet giant

Images are often most of a page's weight. Many CDNs can transform them at the edge: resize to the width actually displayed, convert to WebP or AVIF for browsers that support them, and compress. You upload one large original; each device gets a version that fits. Even without that, serving images from a CDN with long cache times is one of the easiest wins there is.

Security comes along for the ride

• DDoS absorption. A CDN's network is far bigger than your server, so a flood of traffic hits the edge, not your origin.
• A Web Application Firewall at the edge can block common attacks and abusive bots before they reach your app.
• TLS everywhere, with modern protocols handled by the CDN.
• A hidden origin. Lock your origin down so it only accepts traffic from the CDN. For S3 behind CloudFront, origin access control does exactly that, so nobody can bypass the CDN and hit the bucket directly.

The mistakes that hurt

Caching personal pages. The classic incident: a page with a user's name or account data gets cached publicly, and the next visitor sees it. Logged-in pages should send private or no-store, and your CDN rules should never cache responses that set or depend on session cookies.

Ignoring the cache key. The CDN decides "is this the same request?" using the URL and whatever headers or cookies you include in the key. Leave out something that changes the response (like language) and users get the wrong version. Include too much (like every cookie, or User-Agent) and nothing is ever a hit.

Forgetting the origin still matters. A CDN hides a slow origin only for cacheable content. Your API and logged-in pages are as fast as your server, wherever the user is.

Quick start checklist

• Serve built assets with hashed names and a one-year, immutable cache.
• Put images behind the CDN, ideally with resizing and modern formats.
• Mark personal responses private or no-store.
• Lock the origin so only the CDN can reach it.
• Watch the cache hit ratio; if it's low, look at your cache key.

Have you ever been bitten by a CDN serving the wrong thing? I'd love to hear whether it was stale content or something worse.