The Problem CDNs Solve
The fundamental web performance problem that content delivery networks were designed to solve: the speed of light. Data travelling across the internet travels at approximately two-thirds the speed of light through fibre optic cables, and the round-trip time between two physically distant points is irreducible below the time light takes to travel that distance twice. The web server in London responding to a request from Sydney, Australia must exchange data over a path of approximately 17,000 kilometres, producing a minimum round-trip latency of approximately 57 milliseconds from physics alone, plus the processing time at each router hop and the server itself. For a web page that requires ten round trips to load, this adds 570 milliseconds of latency that no amount of server-side optimisation can eliminate.
The CDN solution to the geographic latency problem: distributing copies of web content to servers located in data centres close to users around the world (called edge locations, points of presence, or PoPs), so that the user’s request can be served from a nearby server rather than the geographically distant origin server. The Sydney user who receives content from a CDN edge node in Sydney rather than a server in London experiences latency measured in single-digit milliseconds rather than hundreds of milliseconds, regardless of where the origin server that produced the content is located.
How CDNs Cache and Deliver Content
The CDN caching process that most determines how effectively a CDN improves performance: the cache-control headers that the origin server sends with each response, which specify how long the CDN edge node should store a copy of the content before fetching a fresh copy from the origin. The static content (images, CSS files, JavaScript files, fonts) that does not change between user requests can be cached for days or weeks, allowing the CDN to serve millions of requests for the same content without contacting the origin server at all. The dynamic content (user-specific pages, real-time data, authenticated API responses) that differs between users or requests cannot be cached in the same way and requires either no caching or more sophisticated caching strategies.
The CDN cache invalidation capability that most affects how quickly content changes propagate to users: the ability to purge specific cached content from all edge nodes simultaneously when the content changes before the cache expiry time. The website that deployed a CSS file with a bug and needs to replace it immediately cannot wait for the CDN cache to expire naturally — it needs to purge the cached copies from all edge nodes and have them fetch the updated file from the origin. All major CDN providers offer cache purging APIs that enable this; the speed of purge propagation to all edge nodes (typically seconds to a few minutes for major providers) determines how quickly the updated content reaches users after a purge is initiated.
CDN Security Features
The CDN security capabilities that most extend the CDN’s value beyond performance: DDoS mitigation (the CDN’s distributed infrastructure absorbs distributed denial-of-service attacks by spreading the attack traffic across many edge nodes, each of which can handle a fraction of the total attack volume that would overwhelm a single origin server), Web Application Firewall (WAF) functionality (the rules and machine learning models that examine incoming requests at the edge and block known attack patterns before they reach the origin server), and Bot management (the analysis of request patterns to distinguish legitimate user traffic from automated bot traffic, allowing legitimate bots to pass and blocking or challenging malicious bots).
The CDN DDoS protection mechanism that most accurately explains how CDNs absorb volumetric attacks: the anycast IP routing that allows all CDN edge nodes to share the same IP address range, so that incoming attack traffic is automatically distributed across all edge nodes based on geographic proximity rather than concentrated on a single target. The attack that sends one terabit per second of traffic toward a CDN-protected website distributes across hundreds of edge nodes globally, each receiving a fraction of the total attack volume that their local infrastructure can absorb — while the target website’s origin server is never directly exposed to the attack traffic.
Choosing and Configuring a CDN
The CDN selection criteria that most determine whether a specific CDN is the right choice for a specific website or application: the geographic coverage (the number and location of edge nodes determines the geographic reduction in latency for users in specific regions — the CDN with excellent coverage in North America and Europe may have sparse coverage in Southeast Asia, where many users are located for some applications), the pricing model (CDN providers charge for data transfer, HTTP requests, or a combination — the most cost-effective pricing model depends on the content type and traffic pattern), and the feature set (the WAF, bot management, image optimisation, and edge computing features that different CDN providers offer at different price points).
The CDN configuration that most commonly reduces performance rather than improving it: the misconfigured cache-control headers that prevent the CDN from caching static content that should be cached, resulting in the CDN passing every request through to the origin server and providing no performance benefit for the content that represents the majority of the page’s byte size. The website that has deployed a CDN but serves its images with no-cache headers is paying CDN costs without receiving CDN performance benefits for its most expensive content. The cache configuration audit that checks the cache-control headers on every content type and ensures that cacheable content has appropriate cache lifetimes is the CDN optimisation step that most frequently reveals significant performance improvements available from the already-deployed CDN infrastructure.
Edge Computing: The Next Evolution of CDNs
The CDN capability evolution that most significantly extends what CDNs can do beyond content delivery: the edge computing functionality that allows application logic to run on CDN edge nodes rather than only at the origin server. The edge function (Cloudflare Workers, Fastly Compute, AWS CloudFront Functions) is a small piece of application code that runs on every CDN edge node, processing requests and responses without the latency of a round trip to the origin. The personalisation that was previously only possible at the origin (because the origin server has access to user data) can now be performed at the edge (where the user data is available from a cookie or edge-accessible database), adding minimal latency rather than the round-trip latency to the origin.
The edge computing use cases that most clearly justify the investment in learning the edge programming model: the A/B testing that assigns users to test variants at the edge without a round trip to the origin (reducing latency for the split decision that is otherwise on the critical path of every page load), the authentication that validates tokens at the edge and rejects unauthorised requests before they consume origin server resources, and the geographic routing that serves different content to users in different countries based on their location as detected at the edge node. Each of these use cases benefits from the proximity advantage of edge computation — the decision that must be made for every request is made as close to the user as possible, reducing the latency that the decision would add if made at the origin.