If you've ever wondered how websites deliver content quickly to users around the world, a Content Delivery Network (CDN) is a big part of the answer.
But how does a CDN actually work? How does it route users to nearby servers, cache content, and reduce the load on the origin server?
This post breaks down what a CDN actually is, how it works under the hood, its architecture, real-world examples, and why modern websites rely on CDNs.
Table of Contents
- What is a CDN?
- Why Is a CDN Needed?
- How Does a CDN Work?
- CDN Architecture
- Key Components of a CDN
- What Content Does a CDN Deliver?
- CDN for JavaScript, APIs, and Dynamic Websites
- Caching Strategies
- Real-World Examples
- Popular CDN Providers
- Benefits of Using a CDN
- Challenges and Limitations
- When Should You Use a CDN?
- How to Check Which CDN a Site Uses
- Summary
What is a CDN?
A Content Delivery Network (CDN) is a globally distributed network of servers that delivers content to users from a location close to them, instead of routing every request to a single origin server.
Instead of every user request traveling all the way to your origin server (the main server hosting your website), a CDN stores cached copies of your content on servers spread across the world — called edge servers or Points of Presence (PoPs).
Almost every large website today uses some form of CDN to improve performance, reduce origin-server load, handle traffic spikes, and provide additional security.
Without CDN: User (India) → Origin Server (USA)
With CDN: User (India) → CDN Edge (near India) → Origin (only if needed)
Why CDN is Needed
Imagine your app is hosted on a single server in Mumbai, and users come from Hyderabad, Delhi, London, New York, and Tokyo. Every single request — no matter where it originates — has to travel all the way to Mumbai and back.
Hyderabad ─┐
Delhi ─────┤
London ────┼──→ Mumbai Origin
New York ──┤
Tokyo ─────┘
The farther a user is from the origin, the more latency (network delay) is introduced. A CDN's job is to place cacheable content closer to users so this round trip shrinks dramatically.
How a CDN Works (Step by Step)
Let's trace a real request for https://example.com/logo.png from start to finish.
1. DNS Resolution
The user enters a URL such as:
https://example.com/logo.png
The browser performs a DNS lookup for example.com. If the website uses a CDN, DNS directs the request toward the CDN network rather than sending it directly to the origin server.
2. User Request Reaches the CDN
The request travels from the user's device through their ISP (such as Airtel, Jio, ACT, BSNL) and across the internet toward a suitable CDN Point of Presence (PoP).
CDNs use technologies such as Anycast routing or GeoDNS to route users to an appropriate edge location — often one that is geographically or network-wise close to them.
3. Edge Server Checks the Cache
Once the request reaches the CDN edge server, the CDN checks whether the requested content — /logo.png in this case — is already cached. There are two possible outcomes:
Cache Hit — if /logo.png is already available in the edge cache, the CDN immediately returns it to the user.
Cache Miss — if the content is not available in the edge cache, the CDN sends a request to the origin server.
4. CDN Fetches Content from the Origin
The origin server is the actual server where the website's content is stored.
User
↓
ISP
↓
CDN Edge Server
↓
Origin Server
The origin server returns logo.png to the CDN edge server.
5. CDN Caches the Content
The CDN stores the returned content in its edge cache according to the configured cache rules and TTL (Time to Live). The response is then sent to the user.
Origin Server
↓
CDN Edge Server
↓
User
6. Subsequent Requests
When another user requests the same logo.png and is routed to an edge location that already has the object cached, the CDN can serve it directly:
User
↓
ISP
↓
CDN Edge
↓
Cached logo.png
↓
User
The origin server does not need to be contacted for every request.
7. Cache Expiration
Cached content has a TTL that determines how long the CDN should consider the cached object fresh. Once the TTL expires, the CDN may need to contact the origin server again to obtain a fresh version, depending on the CDN's caching and revalidation configuration.
CDN Architecture
USERS
|
v
DNS
|
v
ISP
|
v
CDN / EDGE LOCATION
|
Cache Hit?
/ \
Yes No
| |
v v
USER ORIGIN
|
v
LOAD BALANCER
|
+--------+--------+
| |
APP SERVER APP SERVER
| |
+--------+--------+
|
DATABASE
If you remember only one diagram from this whole post, remember this one — it's the backbone of every CDN explanation.
Key Components of a CDN
It helps to know the individual pieces that make up a CDN and work together on every request.
a. Origin Server
The original source of truth — where your actual website/app files live.
b. Edge Servers (PoPs — Points of Presence)
Servers distributed across multiple geographic locations that cache and serve content to nearby users.
c. DNS Routing / Anycast
Determines which edge server should handle a given user's request — usually the geographically nearest or least congested one.
d. Cache Layer
Stores static (and sometimes dynamic) content temporarily so it doesn't need to be re-fetched from the origin every time.
e. Load Balancer
Distributes incoming traffic across multiple servers to prevent overload and ensure high availability.
f. Origin Shield
An additional caching layer between edge servers and the origin, reducing the number of direct requests that hit your origin server.
What Content a CDN Delivers
A CDN isn't just for JavaScript files. It commonly handles:
- Static content: images, CSS, JavaScript, fonts, PDFs
- Dynamic content: personalized pages, API responses (via dynamic content acceleration)
- Streaming media: video/audio (YouTube, Netflix use CDNs heavily)
- Software downloads: large files like game updates, installers
- Web applications: full websites via edge computing (e.g., Cloudflare Workers, Vercel Edge Functions)
CDN for JavaScript, APIs, and Dynamic Websites
CDN for JavaScript
This is where the term "JavaScript CDN" often causes confusion.
Consider Bootstrap. Instead of hosting it yourself:
<script src="/assets/bootstrap.js"></script>
you can load it from a CDN instead:
<script src="https://cdn.example.com/bootstrap.js"></script>
The JavaScript file is hosted and distributed through the CDN provider's infrastructure. Popular libraries are commonly distributed this way — jQuery, React, Bootstrap, and countless others are all available via public CDNs like jsDelivr or cdnjs.
It's worth being precise about what's actually happening here: the CDN is not "executing" your JavaScript. It is simply delivering the JavaScript file to the browser — the browser is the one that executes it. The CDN's job ends the moment the file is handed off.
CDN for APIs
A common myth is that CDNs only work for static sites. Not true — CDNs can also sit in front of APIs.
A CDN can route static assets to cache while sending dynamic requests straight to the origin:
CDN
|
+----------+----------+
| |
Static files Dynamic requests
(/assets/*.js) (/api/login)
| |
v v
Cache Origin
Take an endpoint like /api/products. Suppose the product list only changes every 5 minutes — you might configure:
Cache-Control: public, max-age=300
Now many users can be served the cached response instead of hitting your backend on every single request.
But this should only be done when serving a cached response is actually safe — meaning the response is identical for everyone requesting it. Never blindly cache personalized API responses like /api/profile, /api/cart, or /api/orders; doing so risks leaking one user's data to another.
Caching Strategies
CDNs use different caching strategies depending on the content type:
| Strategy | Description | Example Use Case |
|---|---|---|
| Pull CDN | Content is cached only after the first user request | Blogs, general websites |
| Push CDN | You manually upload content to the CDN in advance | Large media files, software releases |
| Time-based expiry (TTL) | Content is cached for a fixed duration | Static assets like logos |
| Cache invalidation/purge | Manually clearing cache when content updates | After a website deployment |
| Stale-while-revalidate | Serves old cached content while fetching a fresh copy in background | News sites, high-traffic pages |
Cache Hit vs Cache Miss
Cache hit — the requested content already exists at the edge, so it's returned immediately with no origin involved.
Cache miss — the content isn't cached yet, so the edge server fetches it from the origin (or another cache tier), caches it, and then serves it — meaning the next request for that same object is likely to be a hit.
TTL, Cache Invalidation, and Cache Busting
TTL (Time to Live) controls how long an object stays cached before it's considered stale and needs to be refreshed from the origin.
Cache invalidation / purging lets you manually clear a cached object — useful right after deploying a new version of a file the CDN is still serving an old copy of.
Cache busting is a common alternative: changing the filename whenever content changes (e.g. app.a82f91.js → app.91bc72.js) so the CDN and browser treat it as a brand-new resource, avoiding stale-cache issues entirely.
Browser Cache vs CDN Cache
These are two separate caching layers that work together:
Browser Cache CDN Cache
└── lives on the user's └── lives across CDN edge
own device locations worldwide
If the browser already has a resource cached locally, it may skip the network entirely. If it does need to fetch it, that request then hits the CDN cache layer next — before ever reaching your origin.
DNS Alone Is Not a CDN
A common misunderstanding: pointing example.com → 1.2.3.4 in DNS does not create a CDN. DNS only tells clients where/how to reach a service — you still need an actual distributed CDN network behind that configuration. Typically your domain is set up with a CNAME (or provider-specific equivalent) pointing to a CDN-provided hostname, e.g.:
www.example.com → d123example.cloudfront.net
Real-World Examples
- Netflix: Uses its own CDN (Open Connect) to cache movies/shows on servers close to ISPs, ensuring smooth streaming without buffering.
- E-commerce sites (Amazon, Flipkart): Serve product images and static assets via CDN so pages load fast during high-traffic sales events.
- News websites: Use CDNs to handle massive traffic spikes when breaking news goes viral, without crashing the origin server.
- GitHub: Uses a CDN (jsDelivr, Fastly) to serve raw files and package assets globally.
- Gaming platforms: Use CDNs to distribute large game updates/patches quickly to millions of users worldwide.
Popular CDN Providers
- Cloudflare — widely used, offers free tier, strong security features (DDoS protection, WAF)
- Akamai — one of the oldest and largest CDN providers, used by enterprises
- Amazon CloudFront — integrated with AWS services
- Fastly — known for real-time purging and developer-friendly edge computing
- Google Cloud CDN — integrated with Google Cloud Platform
- jsDelivr — popular free CDN for open-source JS/CSS libraries and npm packages
Benefits of Using a CDN
- Faster load times — content served from nearby edge servers
- Reduced origin server load — fewer direct requests hit your main server
- Improved scalability — handles traffic spikes gracefully
- Better reliability/uptime — if one edge server fails, traffic reroutes to another
- Enhanced security — many CDNs offer DDoS protection, bot mitigation, and SSL/TLS termination
- SEO benefits — page speed is a ranking factor for search engines
- Bandwidth cost savings — cached content reduces data transfer from the origin
Challenges and Limitations
- Cache invalidation complexity — ensuring users don't see stale/outdated content
- Cost — can get expensive at very high traffic volumes
- Dynamic content limitations — not all CDNs handle personalized/dynamic content well
- Debugging difficulty — issues can be harder to trace since content isn't always coming from your origin
- Vendor lock-in — switching CDN providers can require configuration changes
When Should You Use a CDN?
You should seriously consider a CDN if:
- Your website/app has users spread across different geographic regions
- You serve a lot of static assets (images, videos, JS/CSS bundles)
- You expect high or unpredictable traffic (product launches, sales, viral content)
- You want to improve page speed/SEO performance
- You need extra protection against DDoS attacks
Even small projects and personal blogs benefit from free-tier CDNs like Cloudflare.
Less critical for:
- Small internal tools
- Very low traffic
- Purely private/dynamic requests
- Users concentrated right next to the origin
How to Check Which CDN a Site Uses
Browser DevTools: open Network tab, reload the page, inspect a resource's response headers. Cloudflare, for example, often exposes headers like cf-cache-status and server: cloudflare; other providers have their own signatures.
curl:
curl -I https://example.com
Look for headers like cache-control, age, and server.
DNS lookup:
dig example.com
A CNAME pointing to something like *.cloudfront.net is a strong clue about which CDN is in use.
Note: the exact physical data center a request was served from usually isn't discoverable from public headers — CDN routing is dynamic, and providers generally don't expose exact building/server-level detail.
Summary
A CDN is a globally distributed network of servers that sits between your users and your origin server, caching and delivering content from the location closest to each user — instead of routing every request across the world to a single origin.
The core flow to remember:
User → DNS → ISP → CDN Edge Location → Cache Hit/Miss → Origin (if needed)
On a cache hit, the edge server answers directly. On a cache miss, it fetches from the origin, caches the response according to its TTL, and serves future requests from cache — until that TTL expires or the content is invalidated.
What makes this work, pulled from the post:
- Components — origin server, edge servers/PoPs, DNS/Anycast routing, cache layer, load balancer, and origin shield all work together on every request.
- What gets delivered — not just JavaScript: images, CSS, fonts, video, downloads, and even API responses and full dynamic apps via edge computing.
- Caching strategies — pull vs push CDNs, TTL-based expiry, manual invalidation/purging, and cache busting (renaming files) all exist to balance freshness against performance.
- Not just static sites — CDNs can safely accelerate APIs too, as long as cacheable responses are the same for every user; personalized endpoints should never be cached this way.
- DNS alone isn't a CDN — you need an actual distributed CDN network behind your domain, not just a DNS record. Why it matters: faster load times, less load on your origin, better resilience during traffic spikes, built-in DDoS/WAF protection from most providers, and a real SEO benefit since page speed affects ranking. The trade-offs are mainly cache-invalidation complexity, cost at scale, and slightly harder debugging.
If you're building anything with users spread across regions, or expecting unpredictable traffic, a CDN isn't optional anymore — it's a baseline part of modern web architecture, and even a free tier (like Cloudflare) is worth adding to a small project.
Have you set up a CDN for one of your own projects? Drop the provider you used (and what tripped you up) in the comments — I'd love to hear it.
