CDN (Content Delivery Network)

Core functions

A CDN reduces distance and network hops by serving cached copies of assets from edge locations close to users. It offloads traffic from origin infrastructure, absorbs spikes, and mitigates regional outages by routing requests to healthy points of presence (PoPs). For media-heavy sites, this typically improves time to first byte (TTFB) and overall transfer time, which in turn supports faster rendering and a more stable user experience on varied networks and devices.

Beyond caching, CDNs optimise the transport layer with TLS termination, HTTP/2 and HTTP/3 multiplexing, and connection reuse to minimise round trips. They provide Brotli or gzip compression for text assets, support partial content for media, and offer security controls like DDoS protection and WAF at the edge. Many platforms expose programmable rules to shape traffic, set cache policies, route by geography, and apply image-specific optimisations without touching the application code.

Definition and components

A CDN is a globally distributed network of edge caches fronted by Anycast or DNS-based routing that steers users to nearby PoPs. When an asset is requested, the edge server checks its cache; on a miss, it fetches from the origin, stores a copy according to cache-control rules, and serves it to the user. The behaviour is governed by headers, cache keys (including query strings, cookies, and device hints), and rules that decide whether to cache, compress, or transform content. Visibility is typically provided via real-time logs and cache analytics.

Common components include origin shield layers to concentrate misses and improve fill efficiency, request coalescing to prevent origin stampedes, and edge compute runtimes for programmable logic. Security layers—TLS termination, DDoS mitigation, WAF, bot management, and rate limiting—are often integrated. For image delivery, additional modules provide device-aware routing, format negotiation, and storage integrations while keeping origin credentials and signed-URL logic secure at the edge.

On-the-fly transformations at the edge

Modern CDNs increasingly function as image CDNs, transforming assets in response to request parameters or client capabilities. Typical operations include resizing, cropping, quality adjustments, and automatic format conversion (e.g., WebP or AVIF when the Accept header or Client Hints indicate support). Variants are usually cached at the edge based on a cache key that includes transformation parameters, so subsequent requests for the same dimensions or format are served instantly without reprocessing. This reduces payload size and improves Largest Contentful Paint (LCP), especially on mobile networks.

Transformations introduce trade-offs: more variants can fragment the cache and reduce hit ratio, while CPU-intensive operations at the edge add per-miss latency and may incur higher costs. Correct use of Vary headers (e.g., Vary: Accept, Sec-CH-Width, DPR) and controlled parameter allowlists help avoid unbounded variant creation. Guardrails—such as capping maximum dimensions, stripping unnecessary metadata, and defaulting to conservative quality levels—preserve consistency and performance while maintaining predictable cache behaviour across devices and regions.

Overview

In web performance, a CDN is a foundational layer that shortens fetch times for static and semi-static assets—images, fonts, styles, scripts, and video segments—by serving them from nearby edge locations. The result is faster initial responses, fewer blocked connections, and improved rendering timelines. For SEO and user experience, these gains support metrics like LCP and interaction readiness by reducing network overhead and stabilising delivery during traffic spikes or regional fluctuations in connectivity.

As audiences become more geographically dispersed and mobile-heavy, the variance in last-mile latency and bandwidth grows. CDNs narrow that variance with proximity and protocol optimisations, complementing browser-level techniques such as preconnect, priority hints, and deferred loading. They also provide an operational control plane—cache rules, purges, and analytics—that aligns engineering, product, and SEO teams on delivery reliability and asset hygiene across releases and campaigns.

Scope and purpose

CDNs are best suited to publicly cacheable content: product images, category banners, icons and sprites, CSS and JavaScript bundles, fonts, and downloadable files. They also help with API responses that tolerate short-lived caching or revalidation, and with dynamic HTML via microcaching for burst absorption. For rich media, CDNs distribute HLS/DASH segment files and poster images, while specialist streaming features handle range requests and origin shielding to protect storage layers from thundering herds.

Highly personalised or sensitive content may require bypass rules, token-based access, or signed URLs to ensure privacy and compliance. Teams define the CDN’s remit using cache-control headers, cookie awareness, and route-level policies to avoid caching per-user pages or PII. In image workflows, the purpose often extends to normalising formats, enforcing maximum dimensions, and centralising optimisation policy, so that product imagery remains consistent across devices while minimising origin complexity and media storage duplication.

Cache efficiency vs freshness

Cache efficiency is typically measured by hit ratio and byte hit ratio, both of which correlate with lower origin egress and faster responses. Longer TTLs, versioned URLs, and stable cache keys improve hit ratios, while revalidation headers (ETag and Last-Modified) allow the CDN to confirm freshness without transferring full payloads. Directives like s-maxage, stale-while-revalidate, and stale-if-error balance user-perceived freshness with resilience, keeping previously cached images available while the CDN refreshes objects in the background or during transient origin failures.

Freshness pressure increases with campaign updates and frequent product image changes. Surrogate keys and soft purges enable targeted invalidation without globally flushing the cache, while asset versioning (e.g., /image.v123.jpg) avoids stale content and reduces reliance on purges. Negative caching of 404s prevents repeated origin hits for missing assets, and origin shield plus request coalescing further stabilise fill behaviour under load. The optimal policy aligns TTLs and purge practices with content lifecycles to maximise hit ratios without exposing users to out-of-date visuals.

Implementation notes

Coverage and protocol support matter: choose CDNs with PoPs in key user regions and enable HTTP/2 and HTTP/3 alongside TLS 1.3 for faster handshakes. For images and other static assets, prefer immutable caching with versioned URLs and Cache-Control: public, max-age=31536000, immutable; then override at the CDN with s-maxage or shorter TTLs as needed. Define cache keys explicitly to include the right query parameters and device hints without over-fragmenting. When using edge transformations, restrict accepted parameters, cap dimensions, and attach Vary headers that reflect device-driven changes to ensure correctness and cacheability.

For SEO and analytics, keep static assets on the same hostname where possible to preserve connection reuse and avoid third-party cookie concerns, but serve them from a cookieless path or subdomain to prevent unnecessary cache key bloat from cookies. Validate CORS for fonts and APIs, enable Brotli compression for text, support range requests for videos, and log edge status codes (HIT/MISS/STALE) to observe cache health. Align purge workflows with deployment pipelines, and use origin shield to centralise cache fills when multiple edges fetch the same image variants concurrently.

Comparisons

Origin-only hosting vs CDN

Serving directly from an origin centralises traffic and increases latency for distant users, often resulting in lower cache efficiency at browser level and higher infrastructure costs. A CDN distributes delivery, reduces tail latency, and buffers load during spikes. Origin-only can be workable for intraregional audiences and low-traffic sites, but for image-heavy properties or global reach, a CDN typically yields significantly faster and more stable performance.

Multi-CDN approaches

Multi-CDN uses routing logic to choose among providers by geography or health, aiming for better availability and consistent latency. It adds operational complexity—harmonising cache policies, purges, logs, and TLS across vendors—while potentially fragmenting caches if not planned carefully. Organisations with large, global audiences or strict uptime requirements may benefit, especially for video and image-heavy delivery, provided governance ensures consistent behaviour and observability.

Image CDN vs general-purpose CDN

An image CDN specialises in media transformations—resizing, smart cropping, format conversion, and quality control—exposed via simple parameters and device-aware defaults. A general-purpose CDN focuses on caching and transport optimisation, sometimes offering transformations as an add-on or via edge functions. For teams prioritising visual consistency and payload reduction without custom pipelines, an image CDN can simplify policy enforcement while still leveraging the underlying global edge network.

Reverse proxy caches (e.g., Varnish/Nginx) vs CDN

Self-managed reverse proxies deliver powerful, customisable caching at or near the origin and can handle complex application logic. They lack global PoPs, so they do not reduce geographic latency without additional infrastructure. Many deployments pair an origin proxy with a CDN: the CDN provides global reach and last-mile acceleration, while the origin proxy applies granular rules and shields application servers during cache misses.

FAQs

Does a CDN improve SEO directly?

A CDN does not confer ranking signals by itself, but it helps improve page speed and stability—factors that influence user engagement and Core Web Vitals. Faster image delivery reduces LCP and lowers bounce risk, which indirectly supports SEO outcomes. Correct canonicalisation and consistent content across regions remain essential to avoid duplication or crawl inefficiencies.

How does a CDN affect Core Web Vitals for images?

By reducing TTFB and transfer time for large image files, a CDN can improve Largest Contentful Paint. If it performs edge resizing and modern format conversion, the payload shrinks further, which is especially impactful on slow or high-latency connections. Stable delivery and predictable dimensions also help minimise layout shifts and free up bandwidth for critical CSS and JavaScript.

What headers control CDN caching for images?

Cache-Control (public, max-age, s-maxage, immutable) determines TTLs; ETag and Last-Modified enable revalidation; and Surrogate-Control or CDN-specific headers can override behaviour at the edge. Vary headers signal which request characteristics change the response, such as Accept, DPR, or Client Hints for responsive images. Versioned asset URLs help enforce long-lived caching while allowing precise updates without broad purges.

How should private or user-specific images be handled on a CDN?

Use signed URLs or cookies and short-lived tokens, instruct the CDN to bypass caching for authenticated requests, and scope access by path or headers. Where caching is valuable, consider keyed caches in private buckets or per-user namespaces, but avoid public caches for PII. Apply origin authentication and restrict transformation parameters to prevent enumeration or abuse of transformation endpoints.

How is traffic routed to a CDN edge PoP?

Most CDNs use Anycast IP addressing and smart DNS to route users to the nearest or healthiest PoP based on network topology and real-time conditions. If a PoP becomes congested or unreachable, traffic can be dynamically re-routed to alternate locations. The goal is to minimise end-to-end latency while maintaining high availability during outages and regional events.