📅 Published 12 April 2026

The question is not whether CDNs are faster — they are, by physics. A cached response served from a node 20 kilometres away will always arrive sooner than a response computed by a server 5,000 kilometres away. The real question is whether the complexity, cost, and operational overhead of CDN integration are justified for your site, and how to configure the caching layer so it actually delivers the performance it promises instead of creating a new category of debugging problems.

Having operated sites on both pure origin hosting and CDN-fronted architectures, the performance difference is real but the operational difference is equally significant. Cache invalidation is genuinely one of the hard problems, and getting it wrong means either serving stale content or defeating the purpose of caching entirely.

This page covers the architectural trade-offs, the cache configuration that actually works, and the decision framework for choosing between CDN-fronted and origin-only hosting. The page is part of the web development section and connects to the web performance topic hub.

How CDNs deliver performance​

A CDN operates a network of edge servers (Points of Presence, PoPs) distributed globally. When a user requests a resource, the CDN routes the request to the nearest PoP. If the resource is cached there, the response is served directly without contacting your origin server. If it is not cached (a "cache miss"), the PoP fetches it from your origin, caches it, and serves it — so the next request from any user near that PoP gets the cached version.

The performance benefit has three components:

1. Reduced latency. The physical distance between user and server decreases, reducing round-trip time for every request.
2. Reduced origin load. Cached requests never reach your origin, freeing server resources for requests that genuinely need computation.
3. Connection optimisation. CDN PoPs maintain persistent connections to both users and your origin, eliminating connection setup overhead.

For static sites — which this site is — a CDN caches virtually everything. The origin is contacted only for cache misses (first request after deployment or cache expiration) and for dynamic functions. The effective response time for cached content is the round-trip time to the nearest PoP, which is typically 5–30ms for users in major markets.

Cache configuration that works​

The most common CDN misconfiguration is not setting cache control headers correctly on the origin. CDNs respect your origin's Cache-Control header by default. If your origin sends Cache-Control: no-store or omits the header entirely, the CDN passes requests through without caching — and you have a very expensive reverse proxy instead of a CDN.

For static assets (CSS, JavaScript, images, fonts), set long cache lifetimes with cache-busting through content hashes in filenames:

Cache-Control: public, max-age=31536000, immutable

For HTML pages that change occasionally, use shorter TTLs combined with CDN purge on deployment:

Cache-Control: public, max-age=3600, s-maxage=86400

The s-maxage directive controls the CDN cache duration separately from the browser cache. This lets you cache aggressively at the CDN while keeping browser caches fresh enough that users see updates reasonably quickly.

The hotlink protection considerations documented elsewhere on this site become more complex with a CDN, because the CDN serves cached responses regardless of the referer header unless you configure edge rules to check it.

Cache invalidation​

When you deploy new content, the CDN still has the old version cached. You need to invalidate (purge) stale content. The options:

Purge everything. Simple but aggressive. Every resource is re-fetched from the origin on the next request. Appropriate for small sites where cache misses are inexpensive.

Purge by URL. Invalidate specific resources. Appropriate when you know exactly which pages changed. Requires integration between your deployment pipeline and the CDN's purge API.

Purge by tag. Some CDNs (Cloudflare, Fastly) support tagging cached responses and purging by tag. This lets you tag all pages in a section and purge the section after updating one page within it. The most flexible approach for sites with complex content relationships.

Short TTLs with stale-while-revalidate. Set moderate cache lifetimes (minutes to hours) with the stale-while-revalidate directive, which lets the CDN serve stale content while fetching fresh content in the background. Users always get a fast response, and content freshness lags by at most one TTL period.

Origin-only hosting advantages​

Not every site benefits from a CDN. Origin-only hosting is simpler, cheaper for low-traffic sites, and eliminates cache-related debugging entirely. The advantages:

• No cache invalidation complexity. Every request hits the origin, so content is always current.
• Simpler debugging. There is no intermediate cache layer to suspect when something looks wrong.
• Lower cost for low-traffic sites. CDN pricing is per-request. For sites with minimal traffic, the CDN bill may exceed the cost of a small origin server.
• No vendor dependency. Your hosting is your server. There is no external CDN service that can experience outages or policy changes.

For a site serving a local audience (geographically concentrated users) from a server in the same region, the latency penalty of origin-only hosting is minimal — perhaps 20–50ms additional round-trip time compared to a CDN edge, which is imperceptible for most page loads.

Decision framework​

Use a CDN when:

• Your audience is geographically distributed
• Your content is mostly static or changes infrequently
• You need to handle traffic spikes without scaling your origin
• Performance on mobile and high-latency connections matters to your business

Origin-only is sufficient when:

• Your audience is geographically concentrated near your server
• Your traffic is low enough that a single server handles it comfortably
• Your content changes frequently enough that caching creates more problems than it solves
• Simplicity and control are more important than marginal performance gains

Hybrid approach: Use a CDN for static assets (images, CSS, JavaScript, fonts) while serving HTML directly from the origin. This provides the largest bandwidth and latency savings (static assets are the majority of bytes) while keeping dynamic content simple. Most CDNs support this through path-based cache rules.

For this site, Cloudflare Pages handles both the CDN caching and the build deployment, which eliminates the origin server entirely for static content. The edge computing layer (Cloudflare Workers) handles the dynamic aspects at the edge. This combination represents the optimal architecture for static content sites with occasional dynamic needs.