The Geography of Speed: A Developer's Guide to CDNs

Introduction

You’ve built a perfect Next.js app, but after deploying to us-east-1, your London users are staring at a blank screen. The problem isn’t your code. It’s the speed of light. Data crossing the Atlantic still has to battle physical distance and network congestion between distant AWS regions.

We’ve become so used to the "git push" magic of Vercel and Netlify that we rarely wonder how they actually deliver code globally in milliseconds. I decided to look under the hood at the machinery making this possible.

The TL;DR: A Content Delivery Network (CDN) is a globally distributed network of servers designed to cache and deliver assets from the location physically closest to the end-user.

Let's break down the architecture of how this geography of speed actually operates.

---

The Architecture: How It Works

To understand a CDN, you have to understand the decoupling of your infrastructure into two distinct concepts: The Origin and The Edge.

The Origin Server: This is your source of truth. It's where your main Node.js/Express application lives, where your database resides, and where dynamic, user-specific mutations occur. It does the heavy lifting.

The Edge Servers: Also known as Points of Presence (PoPs), these are lightweight proxy servers scattered across global data centers (London, Tokyo, Mumbai, Frankfurt). Their sole job is to sit between the user and the Origin, caching data to intercept requests before they have to travel across the globe.

The Cache Journey

When a user in London visits your site, they don't explicitly ask to connect to the London edge server. The magic happens via Anycast DNS, a routing technique that automatically directs the user's IP request to the geographically closest available node.

Here is the lifecycle of a request:

1. The Request — The user's browser requests hero-image.webp.

2. The Routing — DNS routing recognizes the user is in London and directs the request to the London Edge Server.

3. The Cache Miss — If this is the very first time anyone in London has asked for this image, the London Edge Server checks its local memory and finds nothing. This is a Cache Miss. The Edge Server then acts as a proxy, fetching the image from your Origin Server in San Francisco, storing a copy locally, and sending it to the user. This request is slow.

4. The Cache Hit — A millisecond later, a second user in London requests the exact same hero-image.webp. The London Edge Server checks its memory, finds the file, and serves it immediately. This is a Cache Hit. The request never crosses the Atlantic, and the asset loads almost instantly.

---

Types of Content a CDN Handles

CDNs used to be just for static files, but the edge is getting smarter.

1. Static Content

This is the traditional use case. CDNs are perfect for assets that do not change based on who is asking for them:

• Compiled JavaScript bundles
• Global CSS stylesheets
• Fonts
• Images and videos

2. Dynamic Content & Edge Computing (Advanced)

Modern CDNs now feature distributed compute capabilities. Instead of just caching static files, networks allow you to execute lightweight JavaScript (like Next.js Edge Functions) directly on the edge nodes.

This means you can run logic — like checking authentication tokens, A/B testing variations, or applying internationalized routing — within milliseconds of the user, without ever hitting your primary database.

---

Implementation: The "How-To"

Integrating a CDN depends entirely on the architecture of your stack. Here are the three primary ways to implement edge delivery.

The Easy Way (PaaS Integration)

If you are using the Next.js App Router and deploying to a modern Platform as a Service (PaaS) like Vercel, you get a global CDN out of the box with zero configuration.

When you run next build, the framework automatically hashes your static assets and pushes them to the edge network. Furthermore, any Edge Middleware you write is automatically distributed globally, ensuring that routing logic executes right next to the user.

The Media Way (Specialized Microservices)

Handling media at scale requires more than just caching; it requires on-the-fly optimization. Rather than burdening your main server with image processing, you can offload this to a specialized media CDN like Cloudinary.

By replacing a standard HTML <img> tag with a dynamically constructed Cloudinary URL, the media CDN handles format negotiation automatically. If a user on Chrome requests an image, the CDN converts it to a highly compressed AVIF or WebP format at the edge, caches that specific format, and serves it. The origin server only ever stores the original, high-res source file.

The Custom Way (Reverse Proxy)

If you are managing a custom backend — such as an Express API interacting with a PostgreSQL database — you implement a CDN by placing a service like Cloudflare in front of your server as a reverse proxy.

You change your domain's nameservers to point to Cloudflare. All traffic now hits Cloudflare's edge network first. By configuring caching rules (e.g., instructing the CDN to cache all /api/v1/public-stats endpoints for 60 seconds), you drastically reduce the compute load on your Express server while speeding up response times globally.

---

Conclusion

At the end of the day, building a fast app isn't just about writing clean code or perfectly optimizing your database. It's about geography. The physical distance between your data and your users actually matters.

Whether you let your hosting platform handle the heavy lifting for you or you build out custom delivery services yourself, the golden rule is simple: move your data as close to the people using it as possible. When you bridge that physical gap, you stop making people wait and that’s what makes an app feel truly great to use.