Serving from near the user, and what bandwidth costs

Distance is the part you cannot optimise away

Your server is in one place. Your users are not. A request from Mumbai to a machine in Virginia crosses roughly 13,000 km of fibre, and light in glass manages about 200,000 km/s, so the round trip cannot be faster than about 130 ms; and in practice, with routing, it is 200 to 280 ms. Nothing you write in your handler changes that number.

A content delivery network answers from a machine near the user instead. There are two separate wins in that, and people conflate them:

1. The cached response never travels far. An image served from a point of presence in Mumbai arrives in 20 ms rather than 250 ms.
2. Even uncached requests get faster, because the expensive TCP and TLS handshakes complete against the nearby edge, which then reuses a warm, long-lived connection back to your origin. Dynamic HTML that cannot be cached at all still improves, often by 100 ms or more.

The second point is why putting a CDN in front of a fully dynamic site is still worth doing.

Anycast, in one paragraph

A CDN announces the same IP address from hundreds of locations, and the internet’s routing sends each user to the nearest one. That is anycast. It is also why CDNs absorb volumetric attacks well: a flood aimed at one address is spread across every location that answers for it, instead of arriving at your single machine.

The number that tells you it is working

Cache hit ratio. If 95% of requests are answered at the edge, your origin sees one request in twenty and your bill and your CPU both reflect it. If it is 40%, something is wrong, and it is nearly always one of three things:

• A Set-Cookie header on responses that should be anonymous. Most CDNs refuse to cache a response carrying one, which silently disables caching for your whole site.
• Cache-Control: private or no-store applied globally by a framework default.
• Query strings that vary per user: a tracking parameter appended to every link makes every URL unique.

Check the response headers your origin actually sends, not the ones you believe it sends:

curl -sI https://example.com/logo.svg | grep -i -E 'cache-control|cf-cache-status|age|set-cookie'

Age tells you how long the edge has held the copy. A status header naming a hit or a miss is provided by most CDNs, and watching it change as you reload is the fastest way to learn your own configuration.

Bandwidth is where the money is

Compute costs are predictable. Egress (data leaving a provider’s network) is the line that surprises people, and the prices differ by more than an order of magnitude between vendors.

As a rough shape at the time of writing: the large clouds charge in the region of 8 to 12 US cents per gigabyte out to the internet, with the first 100 GB or so free each month. Several CDN and object-storage products charge nothing at all for egress to the internet as a deliberate competitive position, and some VPS providers bundle terabytes into a flat monthly fee.

The arithmetic that matters: one 2 MB hero image on a page viewed a million times a month is 2 TB of egress. On a metered provider that is a few hundred dollars for one image. Behind a CDN with a 95% hit rate and free egress, it is close to nothing.

So the order of operations for bandwidth cost is: make the assets smaller first (a WebP or AVIF version of that image is often 200 KB), then serve them from an edge that does not meter egress, then worry about the origin.

What a CDN does not fix

• Personalised HTML. A page that says “Hello, Priya” cannot be shared between users. Either split it (cacheable shell, personalised fragment fetched separately) or accept an origin hit.
• Writes. A POST goes to the origin, every time, from wherever the user is. Sign-up forms and checkouts feel the distance even on a heavily cached site.
• A slow origin. A cache miss is your normal latency plus one extra hop.
• Correctness. A CDN will faithfully serve a wrong response to the whole world for as long as you told it to. The cache-key and private-data warnings from the caching lesson apply with a much larger audience.

Edge compute

Several providers let you run small pieces of code at the edge: Cloudflare Workers, Fastly Compute, Deno Deploy, Vercel and Netlify edge functions. It is useful for redirects, authentication checks, A/B splits, header rewriting and serving a cached page while revalidating behind it.

The constraint people meet is data. Your database is still in one region, so an edge function that queries it has crossed the ocean anyway and gained nothing. Edge code pays off when it can answer from the request itself or from edge-local storage; otherwise it is a slower place to run the same query.

The free path

Cloudflare’s free plan gives anycast, TLS, HTTP/3, caching and basic bot protection at no cost, which is the single largest free upgrade available to a small site. BunnyCDN and Fastly are cheap alternatives. If you self-host, a nginx or Varnish cache in front of your app on the same machine gets you the caching but none of the geography, worth knowing, because it is often mistaken for having a CDN.