CDN Explained: The Secret Behind Lightning-Fast Websites
Let’s understand CDN like a 5-year-old.
Imagine your favorite toy is kept in one house very far away. Every time you want to play with it, you have to wait a long time for it to arrive. That’s a website without a CDN.
Now imagine there are many copies of your toy kept in houses all around your neighborhood. So whenever you want it, you get it from the closest house really fast. That’s a website with a CDN.
Here, toys are nothing but your website assets (images, videos, JS, CSS, etc.). So without a CDN, your website assets stay at the origin server, which can be 1000s of miles away, making it slower.
With a CDN, there will be a server near your geographic location that stores a copy of those website assets, allowing content to load much faster. Overall, a CDN caches content across global edge servers, while more advanced caching (often available in higher plans) further optimizes how and where content is stored for even faster delivery.
Limitations of CDN
A CDN mostly stores static assets which is data that doesn’t change from user to user. For example, when any user loads this blog, the above image won’t change; it will be the same for all users. The same goes for JS content, CSS and static HTML.
It cannot store dynamic assets; such as, on a shopping site, the cart page content. The URL remains the same, but for every user the cart content will be different, so it cannot be cached and will always be served from the origin server.
Role of Cookie & Authorization header
When you keep something in a website’s cart and reload your browser, your items are still in the cart. But when you open the same site from a different device, the cart is empty. How does the site know who is opening what?
This is where the cookie/authorization header comes into the picture. Each user is given a key by the server, and it gets stored in the browser. In all subsequent communication (reloading, navigating, API calls), the browser sends the cookie/authorization header back to the server so it can craft specialized content for that user.
Once a cookie/authorization header is sent by the browser, the CDN assumes the server response will be dynamic, so it may bypass caching; effectively not using the CDN at all.
Needless to say, there are some advanced configurations to bypass this.
Lets see caching in action with Chrome Dev Tools
Response from an edge-caching-enabled CDN server looks like this:
Lets understand these three response header coming from CDN server:
Response Header Value
Cache Control : public, max-age=0, s-maxage=2592000
cf-cache-status : HIT
cf-ray : 9e0f3d185eaddc75-HYD
Let's break it down.
Cache-Control:
Let’s understand all three parts in it:
public : The response can be cached by any cache — browser, CDN, etc.
max-age=0 : For browsers (client-side caches), do not cache.
s-maxage=2592000 : For shared caches (like CDNs), the response can be cached for 2,592,000 seconds (~30 days) without revalidation.
cf-cache-status
HIT : Served directly from Cloudflare cache (fastest). No request went to your origin server.
MISS : Not in cache, so Cloudflare fetched it from your origin.
EXPIRED : Was in cache, but expired → fetched fresh from origin.
BYPASS : Cache was skipped entirely (often due to headers like no-cache, cookies, auth, etc.).
DYNAMIC : Cloudflare decided not to cache this content.
STALE : Served old content because the origin didn’t respond in time.
cf-ray
This uniquely identifies a request as it passes through Cloudflare’s network. The first part is nothing but a unique ID, which is used internally by Cloudflare, and the last part is the 3-digit data center code that handled the request.
For example:
SIN = Singapore
BOM = Mumbai
DEL = Delhi
Here is an example of CDN BYPASS response and its impact:
Here you can clearly see that the cache status is DYNAMIC (Cloudflare decided not to cache this content). If you see the second screenshot, it waited for the origin server to respond, which took 1.40s. Once the response was generated, it only took 720ms to download the content from the origin server to the browser.
Here is an example of CDN HIT response and its impact:
If you see in this example, the cache status is HIT (response sent from Cloudflare cache). It only took 81.60 ms to respond (from Cloudflare cache, not origin server), which is very fast compared to the previous case.
