Content Delivery Network (CDN)

A content delivery network is a distributed system of servers positioned in many geographic locations that serve content to visitors from a point near them, rather than from a single origin server. By reducing the physical distance a request must travel, it lowers latency, and by absorbing requests at the edge it reduces load on the origin infrastructure.

Latency reduction is the primary mechanism and is more consequential than it appears, because the effect compounds across the many round trips involved in loading a page. Connection establishment, TLS negotiation, and each subsequent request all incur the round-trip time, so serving from a location fifty milliseconds away rather than three hundred milliseconds away improves not one measurement but every sequential dependency in the load. For a site with an international audience served from a single region, this is frequently the largest available performance improvement.

Modern content delivery networks do considerably more than cache static assets. They terminate TLS at the edge, apply compression, convert and resize images on the fly, serve modern formats to browsers that support them, cache full HTML responses for pages that permit it, and increasingly execute application logic at edge locations. They also provide security functions, including mitigation of denial-of-service attacks, web application firewalls, and bot management, which for many organizations is as much a reason to adopt one as performance.

Cache configuration is where most of the practical value and most of the risk sits. Cache-control headers determine what is stored, for how long, and under what conditions it is revalidated, and getting this wrong produces either poor cache hit rates, which forfeits the benefit, or stale content served to users, which can be commercially serious when prices, stock levels, or personalized content are involved. Cache key design matters equally: keys that include unnecessary variation, such as tracking parameters, fragment caches per user, or unnecessary device segmentation, split the cache and reduce hit rates without providing anything.

Personalized and dynamic content requires deliberate handling rather than exclusion. Serving a cached page shell with personalized fragments loaded separately, or using edge logic to assemble responses, allows caching to apply to the majority of the content while the user-specific parts remain correct. Sites that mark everything uncacheable because some content is personal typically forfeit most of the available benefit.

Origin protection is a benefit that is frequently discovered only during an incident. A traffic spike from a campaign, a media mention, or a bot wave that would overwhelm origin infrastructure is largely absorbed at the edge when caching is configured well, and passes straight through when it is not. Testing this deliberately, by measuring what proportion of a realistic traffic pattern would reach the origin, is more useful than assuming the network provides protection by its presence. For businesses whose peak trading periods are predictable, verifying cache behavior before the peak rather than during it is the difference between a busy day and an outage.

Purging strategy determines operational confidence. A deployment that changes templates or assets must be able to invalidate the affected cached content reliably and quickly, and the standard approaches, versioned asset filenames combined with tag-based or surrogate-key purging for HTML, are worth establishing before an incident makes them urgent. In practice this configuration sits within web performance work in close coordination with product development, since caching decisions constrain how the application can behave and cannot sensibly be made by either side alone.