If your website runs on a server in Mumbai, a visitor in Mumbai gets a fast response, while a visitor in London or New York waits for every request to travel thousands of kilometres and back. A CDN, or content delivery network, shortens that journey by keeping copies of your content on servers spread around the world. This article explains what is a CDN, what it does beyond speed, where it can cause problems, and how to decide whether your site needs one.
How a CDN works
A CDN is a network of servers, often called edge servers or points of presence, located in data centres across many cities. Your own web server becomes the origin. The usual setup works like this:
- You point your domain at the CDN, either by changing a DNS record (often a CNAME) or by moving your DNS to the CDN provider.
- A visitor's request is routed to a nearby edge server.
- If that edge has a fresh cached copy of the requested file, it serves it immediately. This is a cache hit.
- If not (a cache miss), the edge fetches the file from your origin, delivers it, and keeps a copy for the next visitor.
Because most visitors are served by an edge server close to them, distance-related delay (latency) drops sharply, and your origin handles far fewer requests.
What gets cached
CDNs are best at static assets: images, CSS, JavaScript, fonts, videos and downloadable files. These are the same for every visitor and usually make up most of a page's weight.
HTML pages can also be cached if they are the same for everyone, such as blog posts or product pages viewed by logged-out visitors. Personalized pages, shopping carts, checkouts and admin areas must not be cached, or one visitor could see another's data. CDNs usually decide what to cache from your server's response headers, such as:
Cache-Control: public, max-age=31536000, immutablefor versioned static files, and
Cache-Control: private, no-storefor anything personal. You can inspect what your server sends with our HTTP header checker. Many CDNs also add a response header showing whether a request was a hit or a miss, which is useful when tuning.
Benefits beyond speed
- Lower origin load. With a good cache hit rate, the origin serves only a fraction of requests, so a smaller server can handle more traffic, and sudden spikes from a promotion or news mention are absorbed by the CDN.
- DDoS protection. Large CDNs have enormous network capacity and filtering, and can soak up floods of traffic that would overwhelm a single server.
- Web application firewall (WAF). Many CDNs offer rules that block common attacks such as SQL injection attempts and abusive bots before they reach your server.
- TLS at the edge. The CDN handles HTTPS connections near the visitor, often with automatically managed certificates and modern protocols like HTTP/3.
- Hiding the origin. If the origin's firewall accepts traffic only from the CDN, attackers cannot bypass the CDN's protections by hitting your server directly.
- Image optimization. Some CDNs resize and convert images to modern formats on the fly.
Potential downsides
- Stale content. After you update a file, edges may keep serving the old version until it expires. Use versioned filenames (such as
app.3f9a1.js) for assets and purge the cache when publishing important changes. - Caching mistakes. Caching a page that contains personal data, or ignoring cookies that mark logged-in users, is a serious privacy risk. Test logged-in flows carefully.
- Another dependency. If the CDN has an outage or a misconfiguration, your site is affected even if your server is fine.
- Debugging is harder. Errors can come from the edge or the origin. Learn to read the CDN's status codes and headers.
- Real visitor IPs. Your server sees CDN addresses instead of visitors'. Configure your web server to read the real client IP from the header the CDN supplies, and only trust that header from the CDN's ranges.
- Data location. If you have regulatory requirements about where data is processed, check where the CDN terminates TLS and stores cached content.
Does your website need a CDN?
| Situation | CDN value |
|---|---|
| Visitors spread across countries or continents | High |
| Image-heavy, media or e-commerce sites | High |
| Traffic spikes from campaigns or launches | High |
| Exposure to bots, scraping or DDoS | High |
| Small local business site, visitors mostly near the server | Modest, but security features and free tiers can still be worthwhile |
| Internal applications used only on the office network | Low |
A CDN will not fix a slow application. If the server takes three seconds to generate each HTML page because of slow database queries, the CDN can only help for pages it is allowed to cache. Fix the origin's performance as well; it is often a matter of server tuning and query optimization.
Getting started
- Make sure the origin sends sensible
Cache-Controlheaders. - Lower the TTL on the DNS records you will change, then point them at the CDN. Use a DNS lookup to confirm the new records.
- Start with caching static assets only; add HTML caching later with care.
- Restrict the origin to accept web traffic only from the CDN.
- Test logged-in areas, forms and checkout thoroughly.
Key takeaways
- A CDN serves cached copies of your content from servers close to each visitor.
- It reduces latency and origin load, and often adds DDoS protection and a WAF.
- Control caching with
Cache-Controlheaders and never cache personal pages. - It helps most for global audiences and heavy media, and does not replace a fast origin.