CDN (Content Delivery Network)

A visitor opens your site from another part of the world. Every image request travelling to one distant server can add waiting time and use that server’s bandwidth. A content delivery network, or CDN, provides distributed locations that can serve suitable content closer to visitors.

The origin is the source server. An edge location can keep reusable copies, fetch missing content from the origin and apply delivery rules. Network routing chooses a suitable edge; it is not a promise that every visitor always reaches the geographically nearest building.

Images, stylesheets and other public files are common caching candidates. A user’s private order history needs a different policy. A shared cache must not reuse one customer’s private response for another customer.

Cache-control headers and provider rules determine reuse. A cache key identifies the copy: path, query parameters or other request context may affect the answer. Excluding a meaningful difference can serve the wrong content; including unnecessary differences can create many misses.

Expiry and revalidation decide when a copy must be refreshed. A CDN does not automatically cache every response or detect every origin update. Configure rules deliberately and inspect actual hit/miss behaviour.

Read the public file from Edge A, then update the origin to version 2. Read again from A and compare it with an initial read from B. In this teaching model, A keeps version 1 until its copy is removed; B fetches the new version.

Purge the selected edge or all edges, then read again. This model makes purge immediate for clarity. Real providers have propagation behaviour, and browser caches may still contain copies. The counters track origin fetches, not production latency or network distance.

For versioned public assets, a new filename such as site.v2.css gives the new file a distinct identity. A page must reference that new name; visitors can still hold an old page that references the old asset. Keep required older assets available during the transition.

For a stable URL, use an appropriate lifetime, revalidation or purge process. Purging an edge copy does not automatically clear every browser cache. Review how HTML, assets and API responses are updated together.

If the origin fails, an edge can only serve an existing copy when the policy and provider permit it. A cache miss may still fail. Plan origin recovery, monitor cache-hit ratio and errors, and test both warm and cold caches.

Representative official sources checked 6 October 2026. Provider network size is not a universal guarantee of requests/s, bandwidth or user latency. Measure realistic geography, payloads, cache rules and origin misses.

• Cloudflare provides distributed caching with configurable behaviour. Compare the plan’s features and limits; its default rules are not permission to cache private responses.
• Amazon CloudFront is a managed delivery service that can fit AWS origins. Review current pricing, origin access and cache policies.
• Fastly provides CDN delivery and cache-control capabilities. Evaluate configuration, purge behaviour, support and the selected commercial terms.

Paid services may charge for requests, transfer, features or plans. A low origin bill can still come with edge costs. Compare the full cost under a representative hit rate and traffic mix rather than quoting a single universal price.

A public documentation site

Evaluate broad edge caching and versioned assets. Most visitors can share the same content, but update timing and cold-cache behaviour still matter. Compare measured delivery and cost from the audience’s locations.

A signed-in customer dashboard

Cache public assets separately from private responses. Keep account-specific data out of a shared cache unless the key and policy safely isolate it. A faster wrong answer is not a successful optimisation.

Large media downloads

Evaluate transfer costs, range requests, geographic delivery and origin protection. An edge cache does not replace media access permissions or an origin capacity plan. Test the selected provider with the actual file sizes.

In a pull model, an edge fetches content from the origin when it needs a missing or expired copy. The first request can pay the miss cost. In a push or pre-positioning model, a publishing process distributes content ahead of demand under the provider’s supported contract. That adds publication and storage management.

Prewarming selected popular objects can reduce some cold misses, but it is not proof every edge or browser has the new version. Compare origin load, geography, update frequency and transfer charges, and verify which controls the chosen provider actually exposes.

For large downloads, review range-request handling and cache policy. A regional outage or origin failure still needs an explicit fallback rule; serving an existing copy depends on policy and provider support. Neither delivery model grants access to private content.

A CDN can reduce repeated origin work and improve delivery for suitable content. Hits, misses, freshness, privacy and cache keys decide whether those copies are useful.

Compare providers with actual traffic, geography and costs. Plan publishing and origin recovery; edge delivery is part of the system, not a substitute for its correctness.