What a CDN is and how it makes your website fast worldwide

A CDN (content delivery network) is a network of servers in dozens to hundreds of cities that store copies of your website's files and serve each visitor from the nearest location. Because most of a page load is spent waiting on network round trips, cutting the distance from thousands of kilometers to a few dozen typically makes a site load several times faster for visitors on other continents. A CDN also offloads traffic from your origin server and absorbs spikes that would otherwise take it down.

How a CDN works: edge locations, cache hits and misses

Each CDN location is called a point of presence (PoP), or simply an edge. When you put a CDN in front of your site, your domain's DNS points at the CDN instead of your server. Most large CDNs use anycast, announcing the same IP addresses from every PoP so internet routing delivers each visitor to a nearby one.

The edge then does one of two things:

• Cache hit. The edge already holds a fresh copy and answers immediately. The response travels a few dozen kilometers instead of crossing an ocean.
• Cache miss. The edge fetches the file from your origin, returns it to the visitor and keeps a copy for the next request until its time to live (TTL) runs out.

The physics explain why this matters. Light in fiber travels at about 200,000 km per second, roughly 1 ms of round-trip time per 100 km of fiber path. A visitor in Sydney reaching an origin in Frankfurt typically sees a round trip of 250 ms or more. Before the first byte of HTML arrives, the browser needs at least three round trips (TCP, TLS 1.3 and the HTTP request itself), so the wait is around 750 ms before your server does any work. With an edge in Sydney a few milliseconds away, the same three round trips finish in well under 50 ms.

Even a miss is faster than going direct. The edge keeps warm, reused connections to your origin, so a miss costs one long round trip for the request instead of three for the handshakes plus the request.

What to cache on a CDN: static assets versus HTML

Static assets (CSS, JavaScript, fonts, images, video) are the easy part. Give them fingerprinted file names such as app.3f9a1c.js, cache them for a year and never purge them, because every deploy produces new names. HTML is where the big TTFB gains are, and where mistakes happen. Cache anonymous pages with a short edge TTL and purge on publish. Bypass the cache for logged-in users, carts, checkout and anything personalized.

# Fingerprinted static files
Cache-Control: public, max-age=31536000, immutable

# Anonymous HTML: edge keeps it 10 minutes, browsers revalidate
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60

# Account, cart and checkout pages
Cache-Control: private, no-store

Cache keys decide what counts as the same file

The cache key is the identity of a cached object, usually scheme, host, path and full query string. Every variation creates a separate entry and lowers your hit ratio. Strip tracking parameters such as utm_source, gclid and fbclid from the key, leave cookies out of it unless the content truly depends on them, and remember that each header named in Vary becomes part of the key too.

TTLs and purging

Treat the edge TTL (s-maxage or a CDN rule) and the browser TTL (max-age) as separate settings. Long edge TTLs give high hit ratios, and purging keeps them safe: purge single URLs when a page changes, purge by tag or surrogate key when one product appears on many pages, and avoid purging everything on every deploy, which sends a wave of misses to your origin. Fingerprinted assets never need a purge at all.

Origin shield and tiered caching

A CDN with hundreds of PoPs has hundreds of independent caches. Without tiering, each one misses separately, so a popular page can trigger hundreds of origin requests, each paying the full distance. Tiered caching puts a regional upper tier between the edges and your origin: edges ask the upper tier, and only the upper tier talks to your server. Cloudflare calls this Tiered Cache, CloudFront calls it Origin Shield, and Fastly calls it shielding. Choose a shield location close to your origin. Hit ratios rise, purges and traffic spikes stop hammering your server, and a miss at a distant edge is often answered from the shield instead of the origin.

Beyond caching: TLS at the edge, HTTP/3 and image optimization

TLS termination close to the visitor

The edge completes the TCP and TLS handshakes with the visitor, so connection setup costs a few milliseconds instead of two long round trips. The edge then forwards requests to your origin over connections that are already open and encrypted. Keep that origin leg encrypted and verified (Cloudflare's "Full (strict)" mode, for example) rather than falling back to plain HTTP.

HTTP/3 with one switch

HTTP/3 runs over QUIC, which merges the transport and TLS 1.3 handshakes into a single round trip and copes better with packet loss on mobile networks. Most CDNs enable it with a toggle. Browsers usually learn about HTTP/3 from the Alt-Svc header or an HTTPS DNS record, so a first connection may still use HTTP/2. Our HTTP/3 and TLS 1.3 guide covers the details.

Image optimization at the edge

Many CDNs can convert images to AVIF or WebP based on the browser's Accept header and resize them per device, then cache each variant. That often removes more bytes than any other single change. Pair it with the techniques in our image optimization guide.

CDN setups compared: no CDN, static-only and full-page edge caching

How much a CDN helps depends on what it is allowed to cache. Typical effects for a region on another continent from your origin:

The middle row is the most common setup, and it explains a frequent complaint: "We added a CDN, but TTFB in Asia is still 600 ms." The CDN is doing its job for static files, while every HTML request still travels to the origin. Our guide on how to reduce TTFB covers caching HTML safely.

How to check whether your CDN is caching

Response headers tell you exactly what the edge did. Fetch a URL twice and compare:

curl -s -D - -o /dev/null https://www.example.com/ | grep -i -E "^(cf-cache-status|x-cache|age|cache-control|set-cookie|vary):"

• cf-cache-status (Cloudflare): HIT came from cache; MISS was fetched from the origin and stored; EXPIRED, REVALIDATED, UPDATING and STALE describe refreshes; BYPASS means the origin or a rule prevented caching; DYNAMIC means the response was not eligible, the default for HTML. The full list is in Cloudflare's cache status documentation.
• x-cache (CloudFront, Fastly and others): values such as Hit from cloudfront, Miss from cloudfront or HIT. With shielding enabled you may see two values, one per cache tier.
• age: seconds the response has spent in a shared cache, defined in RFC 9111. Any value above zero means a cache answered.
• cf-ray ends with the airport code of the Cloudflare location that answered, such as -NRT for Tokyo, which confirms the request stayed nearby.

Expect MISS then HIT. Remember that each PoP keeps its own cache, so a hit in your city says nothing about Sydney.

How a CDN changes your 8-region speed test results

The clearest proof is a before-and-after comparison. Run a free 8-region speed test without the CDN (or with HTML caching off), change one thing, then test again.

• Without a CDN, the origin region looks fine while far regions show long TCP and TLS segments and a server wait of roughly the origin's TTFB plus the round trip. When the slowest region takes more than 2.2 times as long as the fastest and over 2 seconds, the report flags that distant visitors wait much longer.
• With a static-only CDN, far-region load times and repeat-visit transfer sizes drop, but far-region TTFB still grows with distance from your server.
• With full-page edge caching, TTFB converges across all eight regions, typically under 100 ms. The "origin" label then simply marks whichever region reached the fastest edge and no longer shows where your server is.

Worst-region numbers usually improve the most, and they matter for the grade: A+ requires a worst-region TTFB of 1.5 s or less and a load time of 3 s or less, plus an 8-region average TTFB of 800 ms or less. The first test after a purge can hit cold edges, so run it twice and treat the second run as steady state. For repeat visits, long-lived static caching should make the second load faster in nearly every region (A+ needs 80%), as our browser caching guide explains. See the methodology for how each timing is captured.

Common CDN mistakes that silently disable caching

When a CDN seems to do nothing, the cause is almost always a header from the origin. Check for these four first.

• Set-Cookie on cacheable pages. Most CDNs will not cache a response that sets a cookie, and forcing them to is worse, because one visitor's session cookie could be served to everyone. Common culprits are sessions started on every request, server-side A/B testing and CSRF tokens on public pages. Set cookies only on routes that need them.
• Vary: * and overly broad Vary headers. Vary: * tells caches the response depends on unknowable inputs, so shared caches cannot reuse it. Vary: User-Agent or Vary: Cookie splits one page into thousands of cache entries. Keep it to Vary: Accept-Encoding, plus Accept where the CDN negotiates image formats.
• no-store everywhere. Some frameworks and security plugins send Cache-Control: no-store, no-cache, must-revalidate on every response, including CSS, JavaScript and images. The CDN reports BYPASS or MISS forever and repeat visits never get faster. Reserve no-store for genuinely sensitive pages.
• Query-string cache busting done wrong. style.css?v=42 only works if the query string is part of the cache key. If the CDN ignores query strings, visitors keep the old file after a deploy. A version value regenerated on every request, such as the current timestamp, defeats caching entirely. Fingerprinted file names with immutable avoid both problems.