What Is a CDN and How It Speeds Up Your Site

The problem: distance is latency

Data travels at a finite speed. A request from a user in Sydney to a server in Virginia crosses roughly 16,000 km each way. Even at the speed of light in fiber, that's tens of milliseconds per round trip — and a typical page load makes *many* round trips (TLS handshake, HTML, then CSS, JS, images). Distance compounds into seconds of perceived slowness.

A Content Delivery Network (CDN) attacks this directly: instead of every user reaching your single origin server, the CDN keeps copies of your content on servers spread across the globe, and serves each user from the one nearest them.

How a CDN is structured

The core concept is the Point of Presence (PoP) — a cluster of cache servers in a particular geographic location (a city, an internet exchange). A large CDN has hundreds of PoPs worldwide. When a user requests your site:

1. 1DNS (often anycast) routes them to the nearest PoP.
2. 2If that PoP has a fresh cached copy (a cache hit), it serves it immediately — fast, and your origin never sees the request.
3. 3If not (a cache miss), the PoP fetches from your origin, serves the user, and *stores* the copy for the next person.

So the first user in a region warms the cache; everyone after them gets the fast path.

Static vs dynamic content

CDNs are most obviously powerful for static assets — images, CSS, JS, fonts, videos, and static HTML. These don't change per user, so they cache beautifully.

Modern CDNs also accelerate dynamic content:

• Connection optimization: keep-alive connections from PoP to origin, TLS termination at the edge, HTTP/2 and HTTP/3.
• Route optimization: traffic rides the CDN's private backbone instead of the public internet.
• Edge compute: run logic at the PoP (edge functions) to personalize or assemble responses without a round trip to origin.

Cache control: the headers that matter

The CDN decides what to cache and for how long based on HTTP headers your origin sends. Getting these right is the difference between a fast site and stale content (or no caching at all).

# Cache for 1 year, immutable — ideal for fingerprinted assets like app.4f3a.js
Cache-Control: public, max-age=31536000, immutable

# Cache at the CDN for 60s, but let browsers revalidate
Cache-Control: public, s-maxage=60, max-age=0

# Never cache (e.g. authenticated HTML)
Cache-Control: private, no-store

Key directives:

Cache busting and invalidation

The oldest joke in computing: there are two hard problems, and one is cache invalidation. Two patterns solve 95% of it:

1. 1Fingerprinted filenames. Build tools emit app.4f3a9c.js. The content hash is in the name, so a new build = a new URL. You can cache these immutable for a year and never worry — new deploys reference new filenames.
2. 2Purge/invalidation. For things you can't fingerprint (like index.html), call the CDN's purge API on deploy to evict the old copy.

Keep your HTML on a short TTL (or purge it) and your fingerprinted assets on a long one. That combo gives instant deploys with maximum caching.

Beyond speed: what CDNs also buy you

• DDoS absorption: the distributed edge soaks up volumetric attacks before they reach origin.
• TLS/SSL at the edge: certificates and modern protocols handled for you.
• Origin shielding & offload: fewer requests hit your origin, so it needs less capacity.
• WAF / firewall rules at the edge.

Measuring it

The metric that tells the story is cache hit ratio — the percentage of requests served from cache without touching origin. Higher is better; a well-tuned static site can exceed 95%. Check the response headers your CDN adds (often something like cf-cache-status: HIT or x-cache: Hit) to see whether a given asset is being cached.

curl -sI https://example.com/app.4f3a.js | grep -i cache
# cache-control: public, max-age=31536000, immutable
# cf-cache-status: HIT

If you see MISS repeatedly on a static asset, your cache headers are probably wrong (missing Cache-Control, a cookie defeating the cache, or a Vary header fragmenting it).

How this works on a platform

You shouldn't have to hand-configure a CDN for a static site. On PandaStack, static sites (React/Vite, Astro, Hugo, Next export, plain HTML, and more) are served through Cloudflare at the DNS/edge layer, with automatic SSL and DDoS protection included. The platform sets sensible cache behavior for fingerprinted build output, so your assets get edge-cached without you writing cache headers by hand. Custom domains get automatic SSL on top.

The practical effect: you push a static site, it builds (in a microVM on the pandastack.ai layer), and it's served fast worldwide with the CDN already in front of it.

Common mistakes

• No Cache-Control at all → CDN won't cache, every request hits origin.
• Caching authenticated HTML publicly → one user sees another's data. Use private, no-store.
• Setting cookies on static assets → many CDNs won't cache responses with Set-Cookie.
• Over-broad Vary headers → fragments the cache into near-uselessness.
• Forgetting to purge HTML on deploy → users see the old page.

References

• [Cloudflare: What is a CDN?](https://www.cloudflare.com/learning/cdn/what-is-a-cdn/)
• [MDN: HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)
• [MDN: Cache-Control header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)
• [Google web.dev: HTTP caching](https://web.dev/articles/http-cache)
• [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111)

---

Want a static site served fast worldwide with a CDN, SSL, and DDoS protection already wired up? PandaStack does it automatically when you connect a repo. Try the free tier at [dashboard.pandastack.io](https://dashboard.pandastack.io).