Every request your visitor makes travels a physical distance. A user in Berlin loading a page hosted in Virginia sends packets across an ocean and back, and light only moves so fast. That round trip is why a site can feel snappy for you and sluggish for someone half a world away. Content delivery networks exist to erase most of that distance, and once you understand how they cache content at the edge, a lot of web performance stops feeling like magic.
What a CDN actually is
A CDN is a network of servers spread across many locations, often hundreds of them, sitting in data centers close to real users. These locations are called points of presence, or PoPs, and the servers inside them are edge servers. Instead of every request going back to your single origin server, the CDN keeps copies of your content on edge servers near the people asking for it.
The result is simple to state and powerful in practice: content is served from a machine a few dozen milliseconds away instead of one several hundred milliseconds away. For images, stylesheets, scripts, videos, and even full HTML pages, that shorter trip is the difference between a page that feels instant and one that visibly loads.
The request flow: cache hits and cache misses
The whole system turns on one decision made at the edge: does this server already have a fresh copy of what you asked for?
When a request arrives, the nearest edge server checks its local cache. If it finds a valid, unexpired copy, that is a cache hit. It returns the content immediately without ever contacting your origin. If it has no copy, or the copy has expired, that is a cache miss. The edge fetches the content from your origin, stores a copy for next time, and then serves it to the user.
The first visitor after content is cached pays the full cost of a miss. Everyone after them, for as long as the copy stays valid, gets the fast path. This is why the second page load of a well configured site is so much quicker than the first, and why traffic spikes hurt far less than they would without a CDN: the origin sees a fraction of the requests.
On a hit the edge answers immediately; only a miss reaches back to your origin.
How your request finds the nearest edge
A fair question is how the request reaches the closest edge server in the first place. Most CDNs use a routing technique called Anycast. The same IP address is announced from many locations at once, and the internet's own routing naturally sends each user to the nearest one. A visitor in Tokyo and a visitor in London can type the same address and land on completely different machines, each close to home.
Anycast also makes the network resilient. If one PoP goes offline, traffic simply routes to the next closest one instead of failing. From the visitor's side nothing changes except a slightly longer trip.
TTL: how long content stays cached
A cached copy cannot live forever, or visitors would see outdated content long after you changed it. Every cached object has a time to live, or TTL, which is essentially an expiration timer. While the timer is running, the edge serves the cached copy. Once it expires, the next request triggers a check with the origin.
The headers that set TTL
You control TTL mostly through the Cache-Control response header your origin sends. A few directives do the heavy lifting:
max-age=SECONDSsets how long browsers and caches may reuse the response.max-age=86400means one day.s-maxage=SECONDSoverridesmax-agefor shared caches like a CDN, so you can cache aggressively at the edge while keeping browser caching short.publicallows shared caches to store the response;privaterestricts it to the user's own browser.no-storeforbids caching entirely, which is right for personalized or sensitive responses.
A common, sensible header for a static asset looks like Cache-Control: public, max-age=31536000, immutable, which tells everyone the file will not change for a year. That works because the file's name includes a content hash, so any change ships as a new URL.
The handful of Cache-Control directives that decide how long your content stays cached.
Serving fast even while revalidating
There is a smarter middle ground between fresh and expired called stale-while-revalidate. It lets the edge serve a slightly stale copy immediately while quietly fetching an updated version from the origin in the background. The current visitor never waits, and the next visitor gets the refreshed content.
This is one of the most useful directives for dynamic-but-not-critical content, like a blog index or a product listing. You get near-instant responses without the risk of every visitor stampeding your origin the moment a TTL expires.
Cache hit ratio: the number that matters
If you measure one thing about your CDN, measure cache hit ratio: the share of requests served from the edge rather than forwarded to origin. A ratio above 90 percent means your origin is mostly idle and your users are mostly fast. A low ratio means you are paying for a CDN but still routing traffic the long way.
Several things quietly drag the ratio down:
TTLs set too short, so content expires before it gets reused.
Query strings and tracking parameters that make identical content look like unique URLs, splitting the cache into many single-use copies.
Cookies on static assets, which many CDNs treat as a signal not to cache.
Aggressive or frequent purging, which throws away good cached copies across every location at once.
For big launches, some teams prewarm the cache by requesting key URLs through the CDN before real traffic arrives, so the first wave of visitors hits a warm edge instead of a cold one.
Keeping content fresh: purging and cache tags
Sometimes you need content gone from the cache right now, before its TTL expires, because you fixed a typo or pulled a product. That is called purging or invalidation. The bluntest version is a full purge that clears everything, which is easy but wasteful: it drops your hit ratio to zero everywhere until the caches refill.
Better options are more surgical. You can purge a single URL, or use cache tags, which let you label related objects and clear them together in one call. Tag every page that shows a given product, and when that product changes you invalidate just those pages, leaving the rest of your cache untouched. Reach for a full purge only when you truly have no narrower option.
What to cache, and what to leave alone
Not everything belongs at the edge. A quick way to think about it:
Cache aggressively: images, fonts, CSS, JavaScript, videos, and other static files. Give them long TTLs and versioned filenames.
Cache carefully: HTML pages and API responses that are the same for many users. Short TTLs plus
stale-while-revalidatework well here.Do not cache: logged-in dashboards, shopping carts, checkout, and anything containing personal data. Mark these
no-store.
Putting it together
A CDN speeds up your site by keeping copies of your content close to your users and serving most requests from those nearby edge servers. Anycast routing gets each visitor to the closest one, TTL and Cache-Control decide how long a copy stays valid, stale-while-revalidate keeps responses fast during refreshes, and cache tags let you update content without wiping everything.
You do not need to tune all of it on day one. Start by putting a CDN in front of your static assets with long TTLs, watch your cache hit ratio climb, then extend caching to pages that can tolerate it. The distance between your server and your users stops being the thing that decides how fast your site feels.