A content delivery network (CDN) works by distributing website content across a network of servers located in different geographic regions. When someone requests a webpage, image, video, or other resource, the CDN directs the request to an appropriate edge server. If that server already has a valid cached copy, it can deliver the content without contacting the website’s original server.
If the content is not available in the cache, the CDN retrieves it from the origin server or another caching layer and delivers it to the user. Eligible content can then be stored for future requests.
This system can reduce network latency, decrease the workload on origin servers, and improve the reliability of content delivery. However, not every request is cached, and a CDN cannot eliminate every cause of a slow website.
What Is a Content Delivery Network?
A content delivery network, commonly called a CDN, is a geographically distributed system of servers designed to deliver internet content efficiently.
Instead of requiring every visitor to retrieve files from one distant server, a CDN can serve copies of suitable content from locations closer to users.
According to Cloudflare’s explanation of content delivery networks, CDNs improve content delivery through geographically distributed infrastructure, caching, and optimized network connections.
A typical CDN involves several important components:
- Origin server: The server or storage system responsible for providing the original content.
- Edge servers: CDN servers positioned throughout different geographic regions to handle user requests.
- Cache: Temporary storage containing reusable copies of content.
- Request-routing system: The mechanism that directs users toward suitable CDN infrastructure.
- Cache policies: Rules that determine which responses can be stored, reused, or refreshed.
For example, a website hosted in the United States might receive visitors from Japan, Germany, and Australia.
Without distributed content delivery, many of those visitors may need to retrieve resources directly from the website’s infrastructure in the United States.
With a CDN, eligible resources can be served from edge locations with more favorable network connections.
A CDN is therefore an additional delivery layer within the broader system explained in How Does the Internet Work?.
How Does a CDN Work Step by Step?
Consider a website that stores its original images and other resources on a server in Virginia.
A visitor in Tokyo opens a page containing an image called:
https://www.example.com/images/photo.jpg
Assume the website is configured to deliver this image through a CDN.
Step 1: The Browser Requests the Content
The visitor enters the website address or opens a page containing the image.
The web browser identifies the resource it needs and prepares a network request.
The requested hostname must resolve to suitable network addressing information.
If the browser does not already have a usable address, it can perform a DNS lookup.
For a CDN-enabled website, the DNS configuration may direct the hostname toward CDN infrastructure rather than directly toward the origin server.
However, DNS-based routing is not the only method.
Some CDN systems also use anycast routing, where multiple geographically distributed servers advertise the same IP address.
The objective is to connect the visitor with a suitable CDN endpoint.
Step 2: The Request Reaches an Edge Server
The visitor’s request travels through the internet toward the selected CDN location.
An edge server is a server positioned close to the network’s point of interaction with users.
An edge location is not necessarily the geographically nearest data center. The selected location depends on factors such as internet routing, network conditions, CDN design, and availability.
For example, a visitor in Tokyo might be directed toward an edge location in Japan.
But the network could select another location if routing or operational conditions make it preferable.
Amazon explains this process in its CloudFront content delivery documentation, which describes how DNS directs requests toward suitable edge locations.
Once the request arrives, the CDN must determine whether it can answer from stored content.
Step 3: The CDN Checks Its Cache
The edge server examines the request and checks whether a suitable cached response is available.
This is called a cache lookup.
The CDN does not simply search for a filename. It typically uses a cache key generated from selected request properties.
For example, those properties may include the requested hostname, URL path, query parameters, or particular HTTP headers.
If the request matches an existing, valid cached object, the CDN can use it.
This is known as a cache hit.
If there is no suitable cached object, the result is a cache miss.
The difference determines whether the CDN can immediately return a stored response or must obtain the content elsewhere.
Step 4: A Cache Miss Triggers an Origin Request
Suppose this is the first request for photo.jpg at the selected edge location.
The CDN has no suitable cached copy.
It therefore needs to retrieve the image.
Depending on the CDN architecture, the edge server may contact the origin server directly or request the content from an intermediate cache.
The origin server is the system designated to supply the original version of the content.
It might be a conventional web server, a cloud object-storage service, or another application endpoint.
The CDN sends the appropriate request upstream.
The origin returns the image and accompanying HTTP response information.
The CDN can then forward the response to the visitor.
If the response is eligible for caching under the configured rules, the CDN also stores a copy.
Step 5: The CDN Delivers the Content
The image travels from the CDN edge location to the visitor’s browser.
The browser receives the image and displays it within the webpage.
For this initial cache miss, the CDN still needed to retrieve the content from upstream infrastructure.
Therefore, the first request does not necessarily benefit from a preexisting nearby cached copy.
The CDN may provide other optimizations, but the full caching benefit typically appears when subsequent requests reuse stored content.
Step 6: Later Visitors Receive Cached Content
Now imagine another visitor in Tokyo requests the same image.
If the request produces the same cache key and a valid copy is still stored at the relevant edge location, the CDN can return that copy directly.
It does not need to retrieve the image from the origin again.
This is a cache hit.
The request can therefore avoid an additional trip between the edge location and the origin infrastructure.
The CDN also reduces the amount of traffic and processing required from the origin server.
One important detail is that a copy cached in Tokyo is not necessarily already present at every other CDN location.
Different edge servers can maintain different cache contents.
The Amazon CloudFront delivery architecture also describes regional edge caches, which provide an additional caching layer between some edge locations and origin servers.
What Is the Difference Between a Cache Hit and a Cache Miss?
A cache hit occurs when the CDN has a valid response that matches the incoming request and can reuse it.
A cache miss occurs when that response is not present in the relevant cache.
| Condition | Cache Hit | Cache Miss |
|---|---|---|
| Suitable content already cached | Yes | No |
| Origin request required | Usually no | Usually yes, directly or through another cache tier |
| Potential latency | Often lower | May be higher |
| Origin server workload | Reduced | May increase |
| Content stored afterward | Existing copy may be reused | Eligible response may be added to the cache |
A cache hit does not mean that every part of the webpage loads instantly.
The browser may still need to download other resources, execute JavaScript, calculate layout, and render the page.
Likewise, a cache miss is not automatically a failure.
It is a normal event when content has not yet been stored, has expired, has been removed, or does not match a previously cached variant.
What Is a CDN Cache Hit Ratio?
The cache hit ratio measures the proportion of eligible requests served from cache.
For a simplified example, suppose a CDN handles 10,000 requests for cacheable resources:
- 8,000 requests are cache hits.
- 2,000 requests are cache misses.
The request-based cache hit ratio is:
8,000 ÷ 10,000 × 100 = 80%
This is a hypothetical calculation, not a measured performance result.
An 80% request hit ratio means that four out of five requests in this example were served from cache.
However, request hit ratio and bandwidth savings are different measurements.
Caching 100 small icons does not necessarily save as much data transfer as caching one large video file.
A website should therefore evaluate both request-based and byte-based cache performance when assessing CDN effectiveness.
How Does CDN Caching Work?
Caching is the mechanism that allows a CDN to store reusable copies of previously retrieved content.
A CDN does not automatically cache every response it receives.
Whether content can be stored depends on HTTP semantics, CDN configuration, response properties, and other caching policies.
What Types of Content Can a CDN Cache?
Common cacheable resources include:
- Images such as JPEG, PNG, WebP, and AVIF files.
- Stylesheets containing CSS.
- JavaScript files.
- Fonts and other static assets.
- Downloadable documents.
- Video segments and certain media resources.
- HTML responses, when appropriate caching rules permit.
A website’s homepage can sometimes be cached, but HTML is not universally cached by default across CDN providers.
Similarly, static assets are not guaranteed to be cached if the configuration or response headers prohibit caching.
The important factor is whether the specific response is eligible for safe reuse.
What Is a Cache Key?
A cache key is the identifier the CDN uses to decide whether an incoming request matches a stored response.
Consider these two image URLs:
https://example.com/image.jpg?width=400
https://example.com/image.jpg?width=800
If the origin uses the width parameter to produce images of different sizes, the CDN must distinguish the two variants.
Otherwise, it could return an image of the wrong size.
CDNs can configure cache keys using properties such as URL paths, selected query strings, headers, and cookies.
Amazon’s CloudFront cache key documentation explains how these request properties affect whether responses can be reused.
Adding unnecessary properties can reduce cache efficiency.
But excluding properties that change the response can lead to incorrect content being served.
The cache key must therefore reflect how the application generates its responses.
How Long Does Content Stay in a CDN Cache?
CDNs use freshness rules to determine when stored responses can be reused without contacting the origin.
These rules often involve a Time to Live (TTL) or equivalent expiration policy.
For HTTP caching, response headers can communicate how long a resource should remain fresh.
Consider this illustrative response header:
Cache-Control: public, max-age=300, s-maxage=3600
Here:
- public indicates that the response may be stored by shared caches, subject to applicable rules.
- max-age=300 gives a freshness lifetime of 300 seconds, or five minutes, for caches using that directive.
- s-maxage=3600 specifies a freshness lifetime of one hour for shared caches, overriding max-age for those caches.
A CDN is generally considered a shared cache.
A browser cache is typically a private cache.
This distinction allows a website to apply different freshness rules to browsers and intermediary caching systems.
The MDN Cache-Control reference explains how directives such as max-age, s-maxage, private, and no-store affect HTTP caching.
CDN-specific configuration may impose additional restrictions or override some origin directives, so actual behavior must be checked against the provider’s policies.
What Happens When Cached Content Expires?
Expiration does not necessarily mean the cached file is immediately deleted from storage.
It means the response is no longer fresh under the applicable caching rules.
The CDN may need to contact the origin to obtain a new version or validate the existing one.
For example, the CDN might send a conditional request using an ETag.
If the resource has not changed, the origin can respond with:
304 Not Modified
This allows the cache to reuse the stored content under the updated freshness conditions.
If the resource has changed, the origin can return an updated response.
Some systems also support stale-while-revalidate, which permits a stale response to be served for a limited period while revalidation occurs, when the applicable rules allow it.
This can reduce the delay that users experience during content refreshes.
How Does a CDN Update Cached Content?
Imagine a publisher replacing an outdated image with a new version while keeping the same URL.
An edge server might still have the previous image cached.
Updating the origin file does not automatically guarantee that every CDN location immediately starts serving the new content.
Several mechanisms help control this process.
Cache Expiration
The CDN can wait until the cached response becomes stale.
It then retrieves or validates the resource according to its caching rules.
This is suitable for content that changes predictably or does not require immediate replacement.
Cache Purging or Invalidation
A website operator can request that the CDN remove specified cached content before its normal expiration.
This process is often called cache purging or invalidation.
For example, removing a cached image can cause subsequent requests to fetch the updated version from the origin or another permitted cache tier.
Amazon’s CloudFront invalidation documentation explains how invalidating files differs from deploying resources under new versioned names.
File Versioning
Another approach is to change the resource URL when its contents change.
For example:
/assets/style-v1.css
becomes:
/assets/style-v2.css
The new filename produces a different cache identity.
As a result, the new resource can be retrieved without requiring every existing cache entry for the older version to expire first.
For production systems, versioning is often implemented through automatically generated filenames or content hashes.
Each technique has advantages.
Expiration reduces operational complexity. Purging enables earlier removal of outdated cached content. Versioning makes updated resources distinguishable from earlier versions.
How Does a CDN Find the Best Edge Server?
A CDN needs to direct users toward infrastructure that can serve their requests efficiently.
This process is sometimes called request routing or traffic steering.
The chosen location is not necessarily the closest server on a map.
Network latency, routing policies, availability, and connection conditions matter.
DNS-Based Routing
Some CDNs use DNS responses to direct browsers toward appropriate edge infrastructure.
For example, the DNS system may provide an address associated with a suitable CDN location.
The CDN can make routing decisions based on network information and its own traffic-management policies.
DNS therefore participates in selecting the service endpoint, but DNS does not determine the entire route that individual packets take.
Anycast Routing
Another approach is anycast.
With anycast, multiple locations advertise the same IP address or address prefix.
The internet’s routing system determines which location receives traffic according to available routes and routing policies.
Cloudflare describes its use of anycast within its CDN reference architecture.
Anycast can provide access to distributed infrastructure without requiring every user to receive a geographically unique destination address.
However, anycast does not guarantee that traffic always reaches the physically nearest server.
Why Does Internet Peering Matter?
CDN providers establish connections with internet service providers and other networks.
These relationships affect how efficiently users can reach CDN infrastructure.
Internet peering allows networks to exchange traffic through agreed interconnections.
A CDN with suitable local interconnections can sometimes deliver content without forcing requests to travel through distant transit networks.
This can reduce latency and improve efficiency under the right conditions.
The final path still depends on the network operators’ routing decisions and available infrastructure.
How Does a CDN Make Websites Faster?
A CDN can improve website performance through several mechanisms.
Reducing the Distance to Content
When reusable content is available at an edge location with low network latency to the visitor, the browser may receive the response sooner than if it had to contact a distant origin.
This reduces the time spent waiting for certain network exchanges.
However, the improvement depends on the requested resource and the actual network path.
Reducing Requests to the Origin Server
An origin server can become overloaded when large numbers of visitors request the same resources.
Caching reduces how often that server must supply identical content.
Instead of processing every image or stylesheet request, the origin may handle only the requests that require new content.
This can free server capacity for dynamic operations.
Improving Delivery of Large Resources
CDNs can deliver images, downloads, and video segments through distributed infrastructure.
Some also offer content compression, image transformation, optimized transport connections, and other performance features.
These capabilities depend on the provider and configuration.
A CDN can improve the delivery path, but it does not automatically reduce the size of every file or optimize every resource.
An Illustrative Latency Comparison
Consider a hypothetical website with the following network conditions:
| Scenario | Assumed Network Round-Trip Time |
|---|---|
| Visitor to distant origin | 150 milliseconds |
| Visitor to nearby CDN edge | 20 milliseconds |
| CDN edge to origin | 140 milliseconds |
These numbers are illustrative, not measured CDN performance.
For a cache hit, certain origin exchanges can be avoided because the requested resource is already available at the edge.
For a cache miss, the CDN must still retrieve content from an upstream source.
This is why repeated requests for cacheable files can benefit differently from first-time requests.
The final webpage loading time also depends on file sizes, bandwidth, connection setup, browser rendering, and application processing.
A smaller network round-trip time does not translate into an identical reduction in total page loading time.
Can a CDN Deliver Dynamic Content?
Yes, but dynamic content requires additional care.
Static content generally returns the same representation to many visitors.
Dynamic content may change depending on the user, session, location, request parameters, or current application state.
Examples include:
- A user-specific account dashboard.
- A personalized shopping cart.
- Live inventory information.
- A search results page.
- An application programming interface (API) response.
A CDN can forward dynamic requests to the origin without caching the response.
Some CDN platforms can also execute certain application logic at edge locations or cache carefully selected dynamic responses.
The correct approach depends on whether a response is safe to reuse.
Why Shouldn’t Everything Be Cached?
Imagine two customers signing in to the same online store.
Their account pages contain different personal information.
If the CDN incorrectly stores one customer’s response in a shared cache and serves it to the other customer, private information could be exposed.
HTTP provides cache directives to help prevent this.
For example:
Cache-Control: private
restricts storage of the response to private caches under HTTP caching semantics.
Cache-Control: no-store
instructs caches not to store the response.
As the MDN HTTP caching guide explains, shared caching requires particular care when responses contain personalized information.
CDN rules, application authentication, and the cache key must work together to prevent inappropriate reuse of content.
How Does a CDN Improve Website Reliability?
A distributed CDN has infrastructure in multiple locations.
This can reduce dependence on one edge location and spread incoming traffic across a larger network.
If one edge server or location becomes unavailable, the CDN may route requests toward another operational location.
Some systems also use multiple origin servers or load-balancing mechanisms.
A load balancer distributes traffic among eligible backend systems according to its configuration.
This can help prevent one server from receiving all the application traffic.
However, edge redundancy and origin redundancy solve different problems.
A CDN may have hundreds of functioning edge servers while the origin application remains unavailable.
If the CDN does not have a usable cached response and cannot reach the origin, it may be unable to fulfill the request.
Some services support serving stale cached content during certain origin failures.
Whether this works depends on the cache policy, content availability, and platform capabilities.
A CDN improves resilience under suitable conditions, but it does not guarantee that a website will never experience downtime.
How Does a CDN Improve Website Security?
Many CDN platforms include security services in addition to content delivery.
These can help protect websites before unwanted traffic reaches the origin.
DDoS Mitigation
A distributed denial-of-service (DDoS) attack attempts to overwhelm a service with traffic or requests.
A CDN with suitable protection infrastructure can absorb, filter, or distribute portions of this traffic across its network.
This may reduce the load reaching the website’s origin.
However, protection depends on the attack type, traffic volume, provider capabilities, and configuration.
Not every CDN provides the same security features.
Web Application Firewall
Some CDN services include a web application firewall (WAF).
A WAF inspects web requests and applies rules intended to identify or block certain unwanted traffic.
This differs from caching.
Caching determines whether a response can be reused, while a WAF evaluates requests according to security policies.
HTTPS and TLS
CDN services often support HTTPS for connections between visitors and edge infrastructure.
In a reverse-proxy configuration, the CDN terminates the visitor’s TLS connection and may establish a separate connection to the origin.
For end-to-end protection across both network segments, the edge-to-origin connection also needs appropriate encryption and authentication.
The distinction matters because an encrypted browser-to-CDN connection does not, by itself, prove that the connection between the CDN and origin is encrypted.
Cloudflare’s CDN reference architecture describes how reverse proxying, caching, DDoS mitigation, and other edge services can operate within the same infrastructure.
A CDN is not a replacement for secure application design, origin protection, software maintenance, or access controls.
What Is the Difference Between a CDN and a Web Server?
A CDN and a web server perform related but different functions.
| Feature | CDN | Origin Web Server |
|---|---|---|
| Primary role | Distributes and accelerates delivery of content | Supplies or generates the original content |
| Geographic design | Often distributed across many regions | May be deployed in one or multiple regions |
| Caching | Common central function | May also support caching |
| Dynamic processing | May proxy requests or run selected edge logic | Often runs core application logic |
| Content ownership | Usually delivers copies or proxied responses | Typically maintains the authoritative application or content source |
For example, a news publisher may operate its application through a web hosting platform.
The publisher’s servers generate articles and manage the site’s database.
The CDN stores and delivers eligible images, scripts, stylesheets, or cached pages from its distributed edge network.
The systems cooperate rather than replacing one another.
This is why a CDN should not be confused with web hosting.
Hosting supplies the environment where a website or application operates.
A CDN focuses on how content and requests are delivered to users, although modern edge platforms increasingly offer additional computing capabilities.
What Is the Difference Between a CDN and a Reverse Proxy?
A reverse proxy sits in front of one or more backend servers.
It accepts requests from clients and forwards requests upstream when necessary.
Many CDNs use reverse-proxy architectures, but the concepts are not identical.
A reverse proxy describes a network role.
A CDN describes a distributed content-delivery system.
A reverse proxy may operate in one data center without providing geographically distributed caching.
A CDN may combine reverse proxying with edge caching, traffic steering, and other network optimizations.
Consequently, many CDN edge servers act as reverse proxies, but not every reverse proxy is a CDN.
How Can You Tell Whether a CDN Is Caching Content?
Some CDN providers include response headers that indicate how a request was handled.
For example, Cloudflare can return a CF-Cache-Status header.
Possible values include:
| Cache Status | General Meaning |
|---|---|
| HIT | Content was served from the CDN cache |
| MISS | Content was not present in the relevant cache |
| EXPIRED | A previously cached response was stale |
| REVALIDATED | A cached response was validated through the provider’s process |
| BYPASS | Caching was bypassed under applicable conditions |
| DYNAMIC | The response was handled as dynamic rather than served from cache |
These labels are Cloudflare-specific and should not be treated as universal headers used by every CDN.
Cloudflare’s cache response documentation explains how these statuses relate to its caching behavior.
Other CDN providers have different diagnostic headers, dashboards, and logging systems.
When evaluating performance, it is also important to distinguish a CDN cache hit from a browser cache hit.
If the browser serves an image entirely from its local cache, it may not send a new request to the CDN at all.
Does Every Website Need a CDN?
No.
A CDN is useful when its capabilities address an actual performance, traffic, reliability, or security requirement.
A website with visitors spread across several regions may benefit from geographically distributed delivery.
A media-heavy service may benefit from caching frequently requested images, video segments, and downloadable files.
A high-traffic website may reduce origin workload by serving reusable content from edge caches.
However, a small website serving users in one region may already provide acceptable performance from its existing hosting infrastructure.
A CDN also introduces configuration responsibilities.
Incorrect caching policies can serve outdated content, create unnecessary cache misses, or expose sensitive information.
The appropriate decision depends on the website’s audience, traffic patterns, content types, and infrastructure requirements.
Why Doesn’t a CDN Always Make a Website Faster?
A CDN cannot eliminate every source of delay.
Several conditions can limit its effectiveness:
- Low cache hit ratio: Frequently missing content requires additional upstream requests.
- Uncacheable responses: Personalized or rapidly changing content may need processing by the origin.
- Slow origin server: A CDN cannot fully compensate for backend delays when requests must reach the origin.
- Large or poorly optimized resources: Caching a large image does not automatically make its file size smaller.
- Client-side processing: Heavy JavaScript and expensive rendering can still delay interaction.
- Unfavorable network routing: The selected CDN location may not provide the best possible path.
- Incorrect cache configuration: Unnecessary cache variations can reduce reuse.
The CDN improves the delivery layer, but website performance depends on the complete path from the server through the network to the browser.
The most useful performance improvements come from identifying the actual bottleneck rather than assuming every slow website needs another caching layer.
A CDN Brings Reusable Content Closer to Users
A content delivery network works by placing distributed delivery infrastructure between users and the systems that supply website content.
When a user requests a resource, the CDN directs the request to a suitable edge location and checks for a reusable cached response.
A cache hit allows the edge to deliver content without fetching it again from the origin. A cache miss may require an upstream request before the content can be delivered and potentially cached.
Routing, cache policies, HTTP headers, and origin configuration determine how this process behaves.
By reducing unnecessary long-distance requests and distributing content delivery across multiple locations, CDNs can improve performance, reduce origin workload, and strengthen reliability.
The fundamental principle is straightforward: instead of making every user retrieve the same content from one distant source, a CDN makes eligible content available from distributed infrastructure closer to where it is needed.