What is CDN (Content Delivery Network)?

A CDN, or Content Delivery Network, is a distributed system that delivers content through servers in multiple network locations. It can keep reusable copies of website files, software downloads and video content nearer to the people requesting them, reducing repeated work at the original server and often shortening the delivery path.

The origin is the server or service that supplies the authoritative content. A CDN edge is a delivery location that receives client requests and applies the configured routing, caching and security policy. An edge can serve a stored response, fetch content from another cache or contact the origin. Using a CDN does not mean every request is cached.

For UK broadband users, the useful question is which part of the path changes. A CDN can improve responsiveness or achievable throughput when distant servers, origin capacity or interconnection are constraints. It cannot increase the physical capacity of your FTTP, FTTC, Ethernet or WiFi link.

This guide connects content delivery to the networking concepts in the Techie Broadband terminology guide. The original examples below separate cache correctness, delivery speed and origin offload so you can assess each without treating them as the same outcome.

What sits inside a Content Delivery Network?

• Origin infrastructure that publishes or generates the content.

• Edge servers at points of presence, often called PoPs, that handle nearby network traffic.

• A steering mechanism that helps select an endpoint or route.

• Cache storage and policies governing which responses can be reused.

• Connections between edge locations, optional upper caches and origins.

• Operational controls for certificates, access, invalidation, monitoring and failure handling.

A PoP is a network presence rather than a promise that one particular file is stored there. Availability depends on eligibility, prior requests, capacity and the provider's distribution method. Some systems fill caches on demand. Others place selected content ahead of demand. A single provider can combine several methods.

CDN, hosting, DNS and browser cache are different

Component	Primary job	Important distinction
Web hosting or origin	Run the site and supply its content	The application and its data still need a working source.
CDN	Distribute delivery across network locations	Caching and origin forwarding can coexist.
DNS	Resolve names and publish endpoint information	Resolving a name does not transfer the website body.
Reverse proxy	Handle requests in front of another service	It can operate at one location without being a CDN.
Browser cache	Reuse responses on one user's device	A local hit may avoid a CDN request entirely.
Edge compute	Run application logic at a distributed location	Executing code is different from reusing a stored response.

An integrated platform can provide origin storage, CDN delivery, DNS and application functions together. Separate their roles when diagnosing a problem, even if the dashboard presents them as one service. A CDN is also not a VPN: it handles content delivery for participating services rather than creating a general private tunnel for your device.

Follow a request from your browser to the content

1. The application resolves the hostname or reuses an existing name lookup and connection.

2. DNS answers and network routing lead the client towards a delivery endpoint.

3. The client establishes a suitable connection and, for HTTPS, authenticates the endpoint's certificate.

4. The CDN applies the request's routing and access rules and determines whether a stored response is eligible for reuse.

5. A usable matching copy can be returned. Otherwise the edge may consult another cache, validate a stored copy or fetch from the origin.

6. The response reaches the device, which processes it and may keep its own permitted copy.

Opening a page normally involves more than one object. The HTML, scripts, stylesheets, images, API responses and video segments can have different hostnames and cache policies. A fast cached image does not establish that the HTML or an account API is cached, and a fast response does not establish that the browser renders the page quickly.

Cloudflare's CDN reference architecture describes tiered caches that let a lower edge consult another cache before contacting the origin. This means an edge lookup that fails locally need not produce a full origin download. Interpret a vendor's status and logs at the layer they actually describe.

Does a CDN always choose the nearest server?

Nearest is useful shorthand, but geographical distance alone does not select every CDN endpoint. DNS steering can return different addresses according to available information. Anycast can make the same address reachable from multiple locations, with network routing selecting the path. Providers can also account for health, capacity and their own traffic policy.

The Anycast Routing guide explains why BGP policy and network topology matter. An anycast address does not guarantee the geographically closest location, the lowest latency or the least loaded server. Two households with different ISPs can therefore reach different delivery paths for the same hostname.

The recursive DNS resolver can affect some DNS based steering decisions. RFC 7871, an Informational document from May 2016, describes optional EDNS Client Subnet information that can carry part of a client's network prefix and also identifies privacy concerns. It is not required for every CDN. Changing DNS is consequently neither a guaranteed speed improvement nor a reliable way to force one location.

Cache hit, miss, bypass and revalidation

Outcome	What it means	What to check
Usable cache hit	A matching stored response is reused	Which cache layer served it and whether policy allows reuse.
Cache miss	The relevant lookup has no usable stored response	Other tiers, object eligibility and whether origin retrieval follows.
Bypass or uncacheable	Policy prevents normal shared reuse	Method, authentication, cookies, headers and matching rules.
Revalidation	A stored copy is checked before reuse	Validator, origin response and time spent checking.
Permitted stale delivery	An older response is served under a specific policy	Allowed duration, workload suitability and origin health.

Revalidation can use a validator such as an ETag. If the representation is unchanged, the origin can respond with 304 Not Modified rather than retransmitting the full body. The intermediary then serves its stored content to the viewer as appropriate. An origin request still occurred, so reduced transferred bytes do not necessarily mean that origin processing disappeared.

Provider labels are not universal HTTP terminology. Cloudflare's cache response documentation distinguishes HIT, MISS, BYPASS, DYNAMIC, REVALIDATED and other outcomes. In that product, DYNAMIC reflects a request judged ineligible for caching, while BYPASS can reflect a response that ultimately cannot be stored. Consult the applicable documentation rather than interpreting every non HIT as a fault.

The Age header is evidence about a stored response's age, not a stopwatch for your connection or proof of the last origin deployment. Cloudflare documents that an upper cache can contribute an inherited age. An upstream origin can also supply Age on a response the edge does not cache. Record the status and relevant layer alongside the header.

The infographic summarises the origin, eligible edge copies and the common hit and miss paths. Its freshness panel is essential: content must be suitable for reuse, not merely present somewhere.

The cache key decides which requests share a response

A cache key identifies the representation a lookup is allowed to reuse. Hostname and path are common inputs; selected query parameters, headers or cookies can also matter. If a response changes according to an input that the cache ignores, two requests may wrongly share content. If the key includes irrelevant high variation inputs, useful reuse can collapse.

Amazon CloudFront's cache key documentation illustrates the distinction between information included in the key and information merely forwarded to the origin. An origin request policy can forward information without creating a separate cached variant. That is safe only when the ignored input does not require a different reusable response.

Illustrative input	If it changes the body	If it does not change the body
Language choice	Separate the language representations	Avoid needless duplicate variants.
Image width parameter	Keep different generated sizes distinct	Normalise equivalent inputs deliberately.
Tracking parameter	Retain it if the application uses it to vary content	Consider excluding it from the key after verification.
Account or session identity	Use an appropriate private delivery design	Do not assume stripping it makes account pages public.

Never ignore all query strings or cookies just to raise a cache hit percentage. First establish what the application does with them. Test different languages, account states and content variants. Correctness comes before reuse, especially when a shared cache can answer requests from multiple people.

Freshness policy and actual provider settings

RFC 9111, HTTP Caching, is the June 2022 Internet Standard for HTTP cache behaviour. Its response directives describe distinct permissions and requirements. The unqualified forms below are a useful starting point, rather than a complete configuration.

Response directive	Core meaning
max-age	Specifies a freshness lifetime in seconds.
s-maxage	Sets shared cache freshness, overriding max-age for that purpose.
no-cache	Requires successful validation before reuse; storage can still occur.
no-store	Prohibits storage of the response under normal semantics.
private	Prevents shared storage; a private cache may still store it.
must-revalidate	Requires successful validation before reusing a stale response.

For a public reusable asset, a policy with max-age=60 and s-maxage=600 can give the browser and shared cache different freshness lifetimes. These values are an illustration, not a recommended policy for every file. Freshness is also not a promise that a provider retains the object until that deadline: capacity management can evict it earlier.

Inspect the active CDN configuration as well as the origin header. Amazon documents that a CloudFront minimum TTL greater than zero can cause caching despite no-cache, no-store or private in the origin response. This is a specific product setting observed in its documentation on 12 October 2026, not a reason to disregard the standard's meanings.

Cloudflare also documents settings that can override origin cache controls. The practical privacy check is therefore the complete deployed behaviour. Sensitive responses need suitable rules, authentication and tests that verify one user cannot receive another user's content. A header on its own does not prove those tests pass.

Why editing the origin does not instantly update every copy

A fresh cached copy can remain reusable after the source changes. Different edge locations can have different admission times, variants or cache states. A browser may hold yet another copy. Updating a file at the origin therefore does not automatically mean that every next request returns that version.

Invalidation or purge asks the CDN to remove or invalidate selected cached content. Check the operation's scope and completion behaviour. A CDN purge does not erase copies already stored in visitors' browsers. AWS's invalidation documentation explicitly distinguishes these layers.

Versioned asset names provide a different mechanism. An application can reference styles.v2.css instead of styles.v1.css, or use a content hash in the filename. The new name must reach the browser through the HTML or manifest that references it. Keep the old asset available while clients may still reference it, and avoid rewriting different content under a supposedly fixed version.

Original Techie Broadband model: two edges, two versions

We ran a deterministic Python 3.12.14 model with two independent caches, A and B. Each keeps a fetched value fresh for 60 simulated seconds. The origin changes from v1 to v2 at second 20. The model fetches on absence or expiry and has no purge, upper tier, browser cache, revalidation or stale delivery.

Time	Edge	Model outcome	Returned version
0 seconds	A	Fetch from origin	v1
10 seconds	A	Reuse stored copy	v1
10 seconds	B	Fetch from origin	v1
30 seconds	A	Reuse stored copy	v1
61 seconds	A	Fetch after expiry	v2
61 seconds	B	Reuse stored copy	v1
71 seconds	B	Fetch after expiry	v2

The verified run produced four origin fetches and three cache hits. At second 61, A returns v2 while B still returns v1: B's copy was admitted later and remains fresh until second 70. Hitting the same URL through a different edge can therefore produce a different version without either cache violating this model's policy.

This is original explanatory modelling, not a measurement of a commercial CDN. It intentionally omits HTTP date and age calculations, validators, clock skew, concurrent fills and configuration propagation. It demonstrates the reason to verify version, cache layer and freshness together; it does not predict an actual provider's update time.

Why UK ISP interconnection matters

Your access line carries traffic between your premises and the ISP, but the ISP must also reach the CDN's network. Interconnection capacity and routing can affect that onward path. A capable nearby edge is useful only if the path to it works well under the conditions you are testing.

Peering can provide a direct interconnection between the relevant networks, while transit provides a different onward relationship. The Peering guide explains why a shorter commercial or network path can help without guaranteeing that every service performs equally.

Netflix Open Connect describes both embedded appliances inside participating ISP networks and interconnection with Netflix facilities. This is a concrete example of content being placed within or close to a provider's network. It does not mean every UK ISP has an appliance or that other services use the same delivery design.

GOV.UK's CDN documentation provides a separate operational example. The manual, updated on 9 July 2026 and checked on 12 October, describes Fastly serving users in front of origins in AWS's Ireland region. It documents a default five minute cache lifetime and a 24 hour grace period for eligible stale homepage delivery during an origin failure. Those values describe that deployment, not CDN defaults.

IPv4 and IPv6 can take different network paths. A resolver change, VPN or mobile connection can also change the observation point and endpoint selection. Keep those differences explicit when comparing results. One slow download or one route trace cannot establish that an ISP's whole network is underperforming.

CDN latency and download throughput are separate

A reusable edge response can avoid the wait for a distant origin and reduce origin queueing. That can improve the first response byte even when the payload transfer rate is unchanged. Conversely, a large file can begin promptly but transfer slowly because a different part of the path limits sustained throughput.

Time To First Byte includes more than network propagation. DNS, connection establishment, encryption, origin processing and intermediary work can contribute, depending on the measurement's start point. Use the TTFB guide when interpreting the waiting stage rather than treating it as a direct broadband speed result.

Protocol support also matters independently of caching. RFC 9114, a June 2022 Proposed Standard, defines HTTP/3 over QUIC, while HTTP/2 commonly operates over TLS and TCP. Connection reuse, multiplexing and transport behaviour can affect results, but HTTP/3 does not guarantee a cache hit or remove a congested access link.

Original transfer calculation: a home origin and a warm edge

Assume a decimal 10 MB public file, a home origin with 20 Mbps of usable upload, a client with 100 Mbps of usable download and a capable external CDN. The file contains 80 megabits. Divide that payload by the relevant bottleneck rate to obtain an ideal transfer minimum.

Delivery case	Assumed payload bottleneck	Ideal 10 MB transfer
Home origin must supply the bytes	20 Mbps home upload	4 seconds
Warm external edge supplies the bytes	100 Mbps client download	0.8 seconds
Warm edge with a capable 1 Gbps client path	1,000 Mbps	0.08 seconds

The first two cases show a fivefold difference in the payload minimum because the serving path changes, not because the client's broadband package changes. On a miss, the origin still needs to supply the bytes unless another tier already has them. Streaming through intermediaries can overlap transfers, so do not simply add every link's full transfer time.

These are theoretical Techie Broadband calculations. They exclude setup delay, protocol overhead, contention, loss, storage and CPU limits. They are not ISP tests, expected page load times or a promise that a home hosted file is eligible for a particular CDN product. Check service terms and actual workload support.

Download Speed remains a constraint on delivery from the CDN to your device. A warm edge can move the bottleneck away from a limited home origin, but it cannot make a 100 Mbps downstream path carry 1 Gbps of payload.

A high request hit rate can hide low byte offload

Consider another original model: 120 requests for 1 MB assets and six requests for 100 MB files. Of the small requests, 108 hit cache and 12 require full origin retrieval. All six large requests miss. Every response delivers its full stated body. There is no compression, range request, upper tier or revalidation.

Group	Requests	Cache hits	Bytes to viewers	Bytes from origin
1 MB assets	120	108	120 MB	12 MB
100 MB files	6	0	600 MB	600 MB
Total	126	108	720 MB	612 MB

The request hit rate is 108 divided by 126, or 85.7%. The bytes served from cache are 108 MB out of 720 MB, or 15%. The remaining 612 MB still comes from the origin. These verified calculations show why a strong request percentage alone can exaggerate the impression of bandwidth savings.

A complete performance review also considers origin request count, bytes, errors, response timing and user outcomes. Revalidation can save body bytes while retaining origin requests. Request collapsing can combine simultaneous work. Provider metric definitions and denominators vary, so compare like with like rather than treating the model as a universal billing formula.

HTTPS, privacy and safe shared caching

When a CDN terminates HTTPS, the browser has an encrypted session with the edge. The edge can process that HTTP content and normally establishes a separate connection to the origin. Verify both legs. A valid browser certificate does not by itself establish origin encryption or origin certificate verification.

Cloudflare's Full (strict) documentation, checked on 12 October 2026, describes origin certificate validation as well as encryption. Other products have their own modes and trust stores. Preserve hostname checks and appropriate trust; disabling verification can hide a configuration fault while weakening the connection.

• Keep authenticated account pages and sensitive API responses out of inappropriate shared caches.

• Test distinct users and sessions before enabling broad caching rules.

• Protect purge credentials, CDN administration and origin access.

• Validate forwarded client information against the trusted proxy boundary.

• Avoid unnecessary sensitive information in URLs and retained request logs.

• Review origin reachability so an attacker cannot simply bypass edge controls.

Cache poisoning occurs when an attacker influences a response that is then stored under a key shared with normal requests. Cloudflare's cache security documentation explains the danger of untrusted inputs affecting content without corresponding key separation. An apparently harmless optimisation can therefore become a correctness or security problem.

Hosting an origin in the UK does not establish that all CDN copies or logs stay in the UK. Google Cloud CDN describes serving locations outside an origin region. Check the service's applicable location controls separately from your origin hosting choice.

DDoS filtering and a web application firewall are additional capabilities, not consequences guaranteed by the letters CDN. They do not repair vulnerable application code. A CDN can also become a shared dependency across several services, so plan monitoring, recovery and configuration changes accordingly.

What happens when something fails?

An edge outage can sometimes be handled by steering traffic to another location. An origin outage can sometimes be hidden by existing eligible copies, a permitted stale policy, another origin or a static mirror. None of those mechanisms guarantees that every uncached or personalised operation continues.

Failure	What may still work	What still needs attention
Origin unavailable	Eligible stored public responses	Cold objects, logins, writes and configured stale limits.
One edge unavailable	Alternative healthy delivery path	Steering behaviour and requests already in progress.
Incorrect shared configuration	Possibly unaffected routes	A routing, cache or certificate error can affect many locations.
Local WiFi or access congestion	Other users' CDN requests	Your own narrow link remains on the delivery path.

A CDN cache is not a backup of the origin database or a durable record of every file. Copies can expire, be evicted or be purged. Restore the authoritative content and application state through a separate tested recovery design.

Troubleshoot the exact failing request

1. Record the hostname, path, time, ISP, device and whether the fault affects one object or several services.

2. Inspect the browser's Network panel for the actual response status, body, timing, cache headers and any local cache indication.

3. Compare repeated requests under controlled conditions without silently changing query parameters, account state or network.

4. Check IPv4 and IPv6 separately where supported, and record whether a VPN or different resolver changes the path.

5. For a site you operate, compare CDN logs with origin logs and the active cache, route and certificate policy.

6. Retest the affected workload after a targeted correction, including a second user or variant when shared caching is involved.

A browser's Disable cache option controls the browser's own cache during the applicable developer tools session. It does not purge a remote CDN. Reloads can also send request directives that change the observed caching path. Record those conditions before comparing a browser result with another tool.

Symptom	Useful checks
Old content after an update	Actual version, origin response, edge freshness, purge scope and browser copy.
Repeated apparent misses	Eligibility, changing key inputs, eviction, purge activity and cache layer.
Fast first byte, slow large file	Payload throughput, WiFi, access capacity, server limits and packet loss.
Slow first byte on a miss	Origin processing, upper tiers, connection setup and origin path.
Only one ISP or address family fails	Endpoint selection, IPv4/IPv6 routes and interconnection evidence.
403 or challenge	Which component issued it, access rules and false positive checks.
502 or 504	Origin reachability, upstream response and timeout logs.
Certificate error or redirect loop	Both TLS legs, expected host, public scheme and proxy configuration.

A status code narrows the investigation but is not a diagnosis. Do not assume every 403 is an ISP block or every 504 is a CDN outage. Determine whether the response came from the edge, a security rule or the application. Supply precise timestamps and request identifiers to the service operator without exposing account tokens.

For site owners: choose and configure around the workload

Cloudflare, Amazon CloudFront, Fastly and Google Cloud CDN are examples of different delivery platforms. Their defaults, integration models and limits differ. Choose around the formats, regions, access policy and operational evidence you need rather than a promise that a CDN is always faster.

• Inventory public assets, HTML, personalised pages, APIs, downloads and streaming workloads.

• Define safe cache keys and freshness for each response class.

• Configure the origin host, transport, certificates and access controls deliberately.

• Plan versioned assets, invalidation, error caching and rollback.

• Measure actual user paths and origin offload before and after rollout.

• Review requests, delivered bytes, origin transfer, invalidation and support costs against the current product terms.

For video, distinguish delivery from encoding and playback. A CDN can distribute encoded segments or files, but it does not automatically encode the source, provide digital rights management or fix a player selecting an unsuitable bitrate. Large downloads and partial requests also need compatible range handling throughout the path.

Begin with a small verified scope and retain a recovery route for configuration mistakes. Test a warm response, a cold response, an updated asset, an origin failure scenario and authenticated user separation. These test different properties; one successful homepage request is insufficient.

Frequently asked questions

Does a CDN make my broadband faster?

It can improve delivery by changing the serving path or reducing origin work. It does not increase the capacity of your broadband line, WiFi or Ethernet connection.

Is a CDN the same as web hosting?

No. Hosting supplies the site or application; a CDN distributes its delivery. One platform can bundle both roles, but the origin and delivery functions remain distinct.

Does every CDN request produce a cache hit?

No. Content may be absent, expired, ineligible, personalised or deliberately bypassed. Another cache tier or the origin may handle the request.

Does no-cache mean the response cannot be stored?

No. In its unqualified HTTP form, it requires successful validation before reuse. no-store expresses a different storage restriction. Verify the CDN's active settings as well.

Why can two people see different file versions?

They can reach different caches with different freshness and admission times, or retain different browser copies. Check the version, key, edge and update policy together.

Can I choose the CDN location as a broadband user?

Usually the service operator and its steering system control delivery. Changing resolver or network can alter some paths, but it does not guarantee a chosen location or better performance.

Key takeaway

A Content Delivery Network changes where content is delivered and how often the original server must do the work. The important checks are the path, the cache key, freshness, safe reuse and the remaining bottleneck. Measure response time, transferred bytes and user experience separately, and remember that a warm CDN does not create extra capacity on your own connection.

Sources and verification

Primary material checked on 12 October 2026 includes IETF RFC 9111, RFC 4786, RFC 7871 and RFC 9114; Cloudflare architecture, caching, TLS and security documentation; Amazon CloudFront cache key, expiry and invalidation documentation; Netflix Open Connect; Google Cloud CDN; Chrome DevTools; and GOV.UK developer documentation. The two cache and traffic models and transfer calculations are original Techie Broadband work. They are explicitly simplified illustrations, not live CDN or UK ISP measurements.