CDNs Explained: How Edge Caching Helps

There is a performance problem no amount of code optimization can fix: the speed of light. If your server lives in Amsterdam and your visitor sits in Sydney, every request travels roughly 16,000 kilometers each way, through cables, routers, and handshakes. Even in ideal conditions, a single round trip costs on the order of 250–300 milliseconds — and loading a page takes several round trips before the first byte of content arrives. Your Sydney visitor experiences a sluggish site not because your code is slow, but because they are far away.

A content delivery network is the industry's answer to geography, and it's conceptually simple: stop making everyone travel to Amsterdam. Put copies of your content in Sydney, and São Paulo, and Singapore, and serve each visitor from the copy nearest to them. Everything else about CDNs is elaboration on that one move. Let's do the elaboration properly, because the details determine whether your CDN actually helps or just adds a logo to your stack.

The physics tax, itemized

To appreciate what a CDN buys, look at what distance actually costs. Before a browser receives a single byte of your page, it typically completes:

1. DNS lookup — finding your server's address (often 1 round trip, sometimes cached).
2. TCP handshake — 1 round trip to establish the connection.
3. TLS handshake — 1 more round trip for the encrypted session (on modern TLS 1.3).
4. The HTTP request itself — 1 round trip minimum for the first response bytes.

Call it three to four round trips before content flows. At 15 ms per round trip (visitor near the server), that's ~50 ms of setup — imperceptible. At 300 ms per round trip (visitor on the far side of the planet), the same setup costs over a second, before your server has done any work at all. Latency, not bandwidth, dominates page load for distant users — a fatter pipe doesn't shorten the round trips.

A CDN attacks this directly: the visitor's connection terminates at an edge server perhaps 20–50 ms away instead of 300. All those handshakes happen against the nearby edge. The physics tax drops by an order of magnitude.

How edge caching actually works

A CDN is a network of servers ("edges" or "points of presence") distributed across cities worldwide — big providers operate hundreds of locations. The mechanics of a request:

1. Your DNS points your domain at the CDN rather than your server. (This is why CDN setup usually starts with a nameserver or CNAME change.)
2. A visitor's request is routed — via anycast or DNS trickery — to the nearest edge.
3. The edge checks its local cache. Cache hit: it serves the copy immediately, and your origin server never hears about it. Cache miss: the edge fetches from your origin, serves the visitor, and keeps a copy for the next person.
4. Copies expire based on caching rules (TTLs — more on those below) or explicit purges, after which the next request refreshes them.

Two consequences follow that people underappreciate. First, the first visitor in each region pays the miss penalty — the CDN is only fast once it's warm, which is why low-traffic sites see less dramatic gains: their caches keep expiring before the next visitor arrives. Second, a CDN is also a shield. Every hit served at the edge is a request your origin never processes — during a traffic spike or a crude denial-of-service attempt, the CDN absorbs the flood while your modest origin server hums along. For many small sites, this survivability is worth as much as the speed.

What caches well, what doesn't, and the modern middle

The traditional CDN setup caches only static assets — safe, easy, and worth having. The bigger prize is full-page HTML caching at the edge for anonymous traffic, which for a typical WordPress blog or brochure site can push the vast majority of all requests off your origin entirely. It demands care: rules must bypass the cache for logged-in sessions (WordPress helpfully sets cookies like wordpress_logged_in_* that CDN rules can key on), cart pages, and previews — and you need a purge hook so publishing a post clears its cached copies. Managed WordPress hosts and CDN plugins wire this up for you; if you're configuring by hand, test the logged-in and cart cases before celebrating your hit ratio.

What a CDN cannot fix

Honest scoping prevents disappointment:

• Slow origin responses on cache misses. If your server takes 2 seconds to generate a page, every miss still takes 2 seconds — now plus a small edge hop. A CDN reduces how often that cost is paid, not the cost itself. Slow database queries and bloated plugins remain your problem.
• Client-side weight. The CDN delivers your 3 MB of JavaScript faster; the phone still has to parse and execute all 3 MB. Render-blocking, long tasks, layout shifts — untouched.
• Nearby audiences with warm caches. If your server is in Frankfurt and most of your customers are in Germany, a CDN's latency win is modest (though the shielding and HTTPS/HTTP2 conveniences may still justify it).
• Uncacheable applications. A member portal where every page is personalized gets connection-termination benefits and static-asset caching, but the headline offload numbers don't apply.

Cache invalidation: the famous hard problem, made manageable

The moment you cache, you create a new bug class: staleness. You fix a typo, the edge in Singapore keeps serving the old page for hours. The three tools, in order of preference:

1. Versioned filenames for assets. When style.css becomes style.9f3ab.css on each change, old cached copies simply stop being referenced. No purging, no staleness, cache forever. Every modern build tool and many WordPress optimization plugins do this. Use it and asset invalidation ceases to exist as a problem.
2. Sensible TTLs for HTML. Cache pages for a modest window — minutes to hours, matched to how often content changes. A 10-minute TTL means worst-case 10 minutes of staleness, usually invisible for a blog.
3. Explicit purges for corrections. Every CDN offers purge-by-URL; WordPress integrations trigger it on post update. Reserve full-cache purges for emergencies — they make every subsequent request a miss and briefly return your origin to full load.

Setting one up without drama

For a WordPress site, the practical path:

1. Check what you already have. Many managed hosts include a CDN — you may be behind one now. Look for CDN response headers (e.g. cf-cache-status, x-cache) in DevTools' Network tab.
2. Start with a reverse-proxy CDN (Cloudflare being the archetype; free tiers exist): move your DNS, leave everything else alone. Static assets get cached with near-zero configuration.
3. Verify HTTPS mode is end-to-end encrypted ("Full (strict)" in Cloudflare terms) — the flexible mode that encrypts only browser-to-edge is a security misconfiguration wearing a convenience costume.
4. Add page caching rules for anonymous HTML once static caching is stable, with logged-in/cart bypasses and purge-on-publish wired through your host or a plugin.
5. Watch two numbers monthly: your cache hit ratio (aim for a high ratio on a content site; a low one means your rules or TTLs need work) and your origin bandwidth (it should have dropped visibly).

The bottom line

A CDN is the rare optimization that attacks a problem you literally cannot code your way out of — distance — and throws in resilience against traffic spikes as a side effect. It is not a substitute for a decent origin server, lean pages, or sane caching headers; it's a multiplier on top of them. If your audience is geographically spread and you're not behind one, this is among the highest-leverage afternoons available to you. If you are behind one, the real question is sharper: what's your hit ratio, and is your HTML riding the edge or just your logo?

Photo: Pixabay on Pexels