A CDN, or content delivery network, is a geographically distributed group of servers that cache copies of your website’s files close to users so content loads faster and your origin server handles less traffic. Instead of every visitor fetching images, scripts, and pages from one central server that might be thousands of miles away, a CDN serves them from a nearby edge location. The result is lower latency, higher throughput, better resilience against traffic spikes, and often built-in security features.
Key takeaways
- A CDN caches content on edge servers spread around the world, close to end users.
- It reduces latency, offloads your origin, and absorbs traffic spikes and some attacks.
- Caching behavior is controlled mainly by the
Cache-ControlandETagheaders. - Static assets cache well; dynamic and personalized content caches less or not at all.
- Use fingerprinted filenames so new deploys invalidate caches automatically.
- A CDN complements your origin server; it does not replace it.
How does a CDN actually work?
When you put a site behind a CDN, DNS is configured so that requests resolve to the CDN rather than directly to your origin. The CDN routes each visitor to a nearby edge server, usually the one with the lowest network latency, using techniques such as anycast routing.
On the first request for a given asset, the edge server has no copy, so it fetches the file from your origin, stores it, and returns it to the user. This is a cache miss. Subsequent requests for the same asset are served directly from the edge without touching the origin, which is a cache hit. Because most visitors request the same popular assets, hit rates are typically high, and your origin sees only a fraction of total traffic.
What is the difference between edge and origin?
The origin is your own server or hosting that holds the authoritative version of your content. The edge is the CDN layer of cache servers distributed globally. Understanding the split matters because it changes how you reason about freshness and debugging.
- The origin is the source of truth; the edge holds temporary copies.
- A change on the origin is not visible to users until the edge cache expires or is purged.
- When debugging, you must know whether a response came from cache or origin, which CDNs expose in response headers.
What content should you serve through a CDN?
Not all content benefits equally. The best candidates are files that are the same for every user and change infrequently.
| Content type | Cacheable? | Notes |
|---|---|---|
| Images, fonts, video | Highly | Large and static; ideal for long cache lifetimes |
| CSS and JavaScript bundles | Highly | Cache long with fingerprinted filenames |
| Static HTML pages | Often | Cache with shorter lifetimes or revalidation |
| API responses | Sometimes | Only if identical across users and not too volatile |
| Personalized pages | Rarely | Mark as private; usually served from origin |
How do you control CDN caching with headers?
Caching is driven mostly by HTTP response headers your origin sends. The most important is Cache-Control.
Cache-Control: public, max-age=31536000, immutableKey directives to know:
publicallows shared caches like a CDN to store the response;privaterestricts it to the browser.max-agesets how many seconds the response is considered fresh.s-maxageoverridesmax-agefor shared caches only, so you can cache longer at the CDN than in the browser.no-cachemeans the cache must revalidate with the origin before reuse;no-storeforbids caching entirely.immutabletells browsers the file will never change, avoiding revalidation requests.
Validators like ETag and Last-Modified let a cache ask the origin whether a stale copy is still valid, and the origin can answer 304 Not Modified to save bandwidth.
How do you invalidate or update cached content?
A frequent source of confusion is why users still see old files after a deploy. There are three main strategies:
- Versioned filenames (recommended). Build tools add a content hash to filenames, such as
app.9f3a1c.js. A new build produces a new filename, which is a new cache key, so users fetch the new file immediately while old files can be cached forever. - Purge or invalidation. Most CDNs offer an API to purge specific URLs or tags. Purges can take a short time to propagate across all edges.
- Short lifetimes. For frequently changing HTML, use a short
max-ageorstale-while-revalidateso content refreshes quickly without a manual purge.
What security benefits does a CDN provide?
Because a CDN sits in front of your origin and operates at large scale, it doubles as a security layer.
- DDoS mitigation. The distributed capacity of a CDN can absorb volumetric attacks that would overwhelm a single origin.
- TLS termination. CDNs handle HTTPS at the edge and can manage certificates for you.
- Web application firewall. Many CDNs offer a WAF to filter malicious requests before they reach your origin.
- Origin shielding. You can restrict your origin to accept traffic only from the CDN, hiding its real address.
A practical pitfall: if your origin logs the client IP, a CDN will make every request appear to come from the CDN unless you read the forwarded client address from headers such as X-Forwarded-For or the provider-specific equivalent.
What are common CDN mistakes to avoid?
- Caching personalized responses publicly. Marking a logged-in user’s page as
publiccan leak one user’s data to another. Useprivatefor anything user-specific. - Forgetting the
Varyheader. If a response differs byAccept-Encodingor language, declare it withVaryso the CDN stores separate variants. - Setting long lifetimes on unversioned files. Without fingerprinting, a long
max-agetraps users on stale assets. - Ignoring cache-hit ratio. Low hit rates mean the CDN adds a hop without the benefit; inspect provider analytics and tune headers.
How do you measure and improve CDN performance?
Adding a CDN does not automatically guarantee a fast site; you have to verify it is doing its job. The single most important number is the cache-hit ratio, the share of requests served from the edge rather than forwarded to the origin. A high ratio means the CDN is absorbing load and cutting latency; a low ratio means requests are constantly falling through to the origin and you are paying for an extra hop with little benefit.
Most providers expose the cache result in a response header so you can confirm behavior per request.
cache-status: HIT
age: 142
x-cache: Hit from cloudfrontWhen hit rates are disappointing, the usual causes are tuneable:
- Missing or short
Cache-Control. If assets are not marked cacheable, every request misses. Add explicit lifetimes. - Cache-busting query strings. Unique query parameters create a new cache key each time; strip or normalize the ones that do not change the response.
- Over-fragmented
Vary. Varying on volatile headers such as the full user agent splits one asset into countless variants that rarely get reused. - Cookies on static assets. Some CDNs bypass the cache when a request carries cookies; serve static files from a cookieless path.
Beyond hit ratio, watch the age header to confirm objects are living as long as intended, and use real-user monitoring to see actual latency by region rather than trusting a single test location.
Frequently asked questions
Does a CDN replace my origin server?
No. A CDN sits in front of your origin and caches copies of its content. The origin remains the source of truth, and the CDN fetches from it on a cache miss or for uncacheable requests.
Can a CDN serve dynamic or personalized content?
Yes, though it caches less of it. CDNs proxy dynamic requests to the origin, and many run edge compute or cache fragments, but per-user content is usually marked private and not shared across users.
How do I force a CDN to serve fresh content?
Change the URL with a version or hash, shorten the cache lifetime with Cache-Control, or issue a purge. Fingerprinted filenames are the most reliable because each version is a distinct cache key.
What is the difference between a CDN and a reverse proxy?
A reverse proxy is a single server that fronts your origin. A CDN is a globally distributed network of such proxies plus caching, routing, and security features spread across many locations.
Does a CDN improve SEO?
Indirectly. Faster load times and better reliability improve user experience and Core Web Vitals, which can help rankings, but a CDN is not a direct ranking signal by itself.
Is a CDN only for large websites?
No. Even small sites benefit from faster global delivery, TLS termination, and DDoS protection, and many providers offer generous free tiers that make adoption low-cost.
What happens if the CDN goes down?
Requests can fail or slow down, since the CDN is in the request path. Good setups use origin failover, multiple CDNs, or DNS-level fallback to reduce this single point of failure.