Content Delivery Networks: A Complete Guide

What a CDN is and why every fast site uses one

A Content Delivery Network (CDN) is a geographically distributed group of servers that work together to deliver internet content quickly. Instead of every visitor hitting your single origin server, a CDN intercepts requests and serves them from the server closest to the user. That server is called a Point of Presence (POP) or edge node. The core idea is simple: move content closer to the people who ask for it.

The first commercial CDN, Akamai, launched in 1998 to solve the "flash crowd" problem that took down websites during major events. Today, every major CDN operates thousands of POPs across dozens of countries. Cloudflare claims 330 cities. Fastly has 60+. Amazon CloudFront has over 600. The number matters, but so does where those POPs are located. A CDN with 100 POPs all in North America won't help a user in Lagos.

What a CDN actually does at each POP

Each POP runs a reverse proxy (often Nginx, Varnish, or a custom kernel) that performs several jobs. The most important is caching: storing a copy of your static assets (images, CSS, JavaScript, fonts) and serving them without contacting your origin. A properly configured CDN can serve 90% or more of requests from cache. The remaining requests that miss cache are forwarded to your origin, and the response is stored for the next visitor.

Beyond caching, a CDN handles TLS termination. The CDN holds your SSL certificate and negotiates the HTTPS handshake with the browser. This offloads expensive cryptographic work from your origin. The CDN then re-encrypts traffic to your origin over a separate, shorter connection. This setup also lets you use modern TLS 1.3 and HTTP/2 or HTTP/3 even if your origin server runs older software.

Compression happens at the edge too. The CDN can store assets in multiple compression formats (gzip, Brotli) and serve the best one for each browser's Accept-Encoding header. Brotli at quality level 4 or 5 typically beats gzip by 20% on HTML and CSS. The CDN handles this transparently.

Why every fast site uses one

Latency is the enemy of user experience. A 100ms delay in page load can drop conversion rates by 7% (Amazon found this in 2006). A CDN reduces latency by cutting the physical distance between the user and the server. Light in fiber travels at about 200,000 km/s. A round trip from Sydney to London takes roughly 160ms just in propagation. A CDN POP in Sydney cuts that to under 10ms.

CDNs also absorb traffic spikes. If your site goes viral and gets 100,000 requests per second, your single origin server would melt. A CDN spreads that load across hundreds of servers. Each POP handles a fraction of the traffic. Your origin only sees cache misses, which stay constant as long as the cache hit ratio holds.

Security is another reason. CDNs provide DDoS mitigation by absorbing attack traffic at the edge. Cloudflare, Akamai, and AWS Shield all offer varying levels of protection. The CDN can also filter malicious requests before they reach your origin, using WAF rules or rate limiting.

Finally, a CDN simplifies operations. You don't need to manage multiple data centers or worry about TLS certificate renewal on every server. The CDN handles the global infrastructure. You focus on your application.

How edge caching actually works

Edge caching is the core mechanism that makes a CDN fast. When a user requests a resource (an image, a CSS file, a JSON API response), the CDN intercepts the request at the nearest edge server. If that server already holds a fresh copy of the resource, it serves it directly to the user without contacting your origin server. This is called a cache hit. If the server does not have the resource, or the stored copy is stale, it is a cache miss, and the edge server fetches the resource from your origin, stores a copy, and then serves it to the user.

The decision of what to cache and for how long is governed by HTTP cache headers sent by your origin. The two most important headers are Cache-Control and Expires. Cache-Control: public, max-age=86400 tells the CDN (and any intermediate proxy) that the response can be cached by any cache and that the cached copy is valid for 86,400 seconds (24 hours). The Expires header provides an absolute expiration date as a fallback for older caches. Most CDNs also respect the s-maxage directive, which overrides max-age specifically for shared caches like the CDN itself.

When a cached resource is still within its TTL (time to live), the edge server serves it immediately. This is the fast path: the request never reaches your origin. When the TTL expires, the edge server must revalidate the resource. It can do this in one of two ways. With a stale-while-revalidate strategy, the edge serves the stale content to the user while it fetches a fresh copy in the background. This eliminates the wait for the user. Alternatively, the edge can perform a conditional request using the If-Modified-Since or If-None-Match headers. If the origin responds with 304 Not Modified, the edge refreshes the TTL without downloading the full payload.

Not all content is cacheable by default. Responses with Cache-Control: private, Cache-Control: no-cache, or Cache-Control: no-store are typically not stored at the edge. Dynamic content, such as personalized dashboards or shopping cart pages, often uses these headers. However, many CDNs allow you to override cache behavior at the edge using rules or configuration. For example, you can force-cache a URL pattern for a short TTL even if the origin sends a no-cache header, or you can strip cookies from cache keys to increase cache hit rates for content that does not actually depend on the user session.

The cache key is the identifier the CDN uses to store and retrieve a cached object. By default, the cache key includes the full URL (scheme, host, path, query string). Some CDNs also include the Vary header, which tells the cache to store separate copies for different values of a request header (like Accept-Encoding for gzip versus Brotli). You can customize the cache key to exclude irrelevant query parameters or to include a custom header, which is useful for A/B testing or geo-specific content.

Edge caching is not a single server holding every file. It is a distributed network of thousands of servers, each caching only the files that users in its region request. A file popular in Tokyo may be cached on every edge in Japan, while a file popular only in London may exist only on European edges. This geographic distribution is what makes the CDN fast: the file is always close to the people who ask for it.

Pull CDN vs push CDN

Not all CDNs fetch content the same way. The two dominant models are pull CDN and push CDN. The choice determines how your origin server interacts with the edge, how you deploy updates, and how much control you have over what gets cached. Understanding the difference is critical when designing a delivery architecture.

Pull CDN

In a pull CDN, the edge nodes fetch content from your origin server on demand. When a user requests a resource that is not yet cached, the edge makes an HTTP request to your origin, caches the response, and serves it. Subsequent requests for the same resource hit the cache until the TTL expires. This is the model used by CloudFront, Cloudflare, Fastly, and most general-purpose CDNs.

Pull CDNs are simple to set up. You point a DNS CNAME or change your origin configuration, and the CDN handles the rest. No manual uploads. This works well for dynamic sites, API responses, and content that changes frequently. Cache control is managed entirely through HTTP headers like Cache-Control and Expires. You can also use origin-pull authentication (signed requests or IP allowlists) to restrict direct access.

The downside: the first request for any uncached resource suffers a cache miss, adding latency. For large files or cold caches, this can be noticeable. Pull CDNs also rely on your origin being available and fast enough to handle peak miss traffic.

Push CDN

With a push CDN, you upload your static assets directly to the CDN's storage platform. The CDN then distributes those files to its edge nodes proactively. There is no origin server involved at serving time. Examples include KeyCDN's Push Zone, BunnyCDN's Storage Zone, and using an object store like Amazon S3 combined with CloudFront (where you push to S3 and CloudFront pulls from S3, but the push is to the storage layer). Some CDNs offer an API or FTP endpoint for uploading files.

Push CDNs eliminate cache misses entirely for the content you upload. Every edge node already has the file, so the first request is served from cache. This is ideal for static assets that rarely change: JavaScript bundles, CSS, fonts, images, video files. You also reduce load on your origin because it never sees a request for those assets.

The tradeoff is operational overhead. You must manage the upload process, handle versioning, and purge old files when you update content. Many push CDNs charge for storage as well as bandwidth, so you pay for keeping files on every edge node. Purging can also be slower than a pull CDN because you need to remove the file from all edge locations.

Choosing between them

Most production setups use a hybrid approach. A pull CDN handles dynamic or frequently updated content (HTML pages, API responses). A push CDN or an origin pull from object storage handles static assets. For example, you might serve your React app's index.html through a pull CDN with a short TTL, while the build/static/js/main.abc123.js file is pushed to a storage zone with a year-long TTL. This gives you the best of both: low latency for immutable assets and easy updates for dynamic pages.

If you are starting out, a pull CDN is the simpler choice. You can always add a push zone later for specific assets. The key is to understand your content's update frequency and whether you can tolerate cache misses on the first request.

Anycast routing: how the CDN sends you to the closest edge

When you request a resource from a CDN, the network must decide which of its dozens or hundreds of Points of Presence (POPs) should serve your request. The answer depends on a routing technique called anycast. Anycast is the mechanism that lets multiple servers in different locations share the same IP address. Your request goes to the nearest one, not a random one.

Most of the internet uses unicast routing. Under unicast, each server has a unique IP address. A DNS lookup returns one IP, and your traffic goes to that single machine. If that machine is in Virginia and you are in Tokyo, your packets cross the Pacific regardless of whether a closer server exists. Anycast flips this model. The CDN announces the same IP prefix from multiple routers around the world. BGP (Border Gateway Protocol, RFC 4271) propagates these announcements. Your ISP's routers pick the path with the shortest AS hop count, which usually corresponds to the geographically closest POP.

How BGP picks the POP

BGP does not measure latency or bandwidth. It counts autonomous system (AS) hops. If the CDN announces 1.2.3.0/24 from London, Frankfurt, and Singapore, your ISP's router sees three routes and selects the one with the fewest AS hops. In practice, this tends to put you on the shortest network path. The result is not always the physically closest city, but it is almost always the closest POP in terms of network topology.

CDNs monitor BGP tables continuously. If a POP goes offline, BGP withdraws its route. Traffic shifts to the next best POP within seconds. This makes anycast a built-in failover mechanism. You do not need a separate load balancer or health-check script for geographic routing.

Anycast and TCP: the connection stickiness problem

Anycast works well for UDP-based protocols like DNS (port 53). A DNS query is a single packet exchange. If the reply comes from a different POP than the query, it does not matter. TCP is different. A TCP connection requires a three-way handshake and maintains state on the server. If your ISP's BGP path changes mid session, subsequent packets may arrive at a different POP that has no record of the TCP connection. The server sends a RST, and the connection breaks.

CDNs handle this with two strategies. First, they use very short BGP timers and route dampening to avoid flapping. Second, they often terminate TCP at the edge POP and proxy the request to the origin over a separate connection. The client talks only to the edge POP. If the BGP route shifts, the client establishes a new TCP connection to the new POPched, and the CDN's internal network forwards the request to the correct origin cache.

Anycast vs. DNS-based routing

Some CDNs also offer DNS-based geographic routing. In that model, the DNS resolver returns different A records based on the resolver's IP address. Anycast is simpler and faster because it does not depend on DNS propagation or EDNS0 support. Most major CDNs (Cloudflare, Fastly, Akamai) use anycast as their primary routing layer. AWS CloudFront uses a combination of DNS routing and anycast at its edge locations.

Cache hit ratio: the single number that determines value

Cache hit ratio is the percentage of user requests served directly from the CDN edge cache without needing to fetch the content from the origin server. It is the single most important metric for measuring CDN effectiveness and cost efficiency. A higher ratio means fewer origin requests, lower origin bandwidth costs, and lower latency for end users.

The calculation is straightforward:

Cache Hit Ratio = (Cache Hits / Total Requests) × 100

Most CDN providers expose this metric in their analytics dashboards. For example, Cloudflare reports this as a percentage per zone, while Fastly provides it in their real-time stats under the hit_ratio field.

Typical cache hit ratios vary by content type. Static assets like images, CSS, and JavaScript often achieve hit ratios above 90% with proper configuration. Dynamic content, such as API responses or personalized pages, typically has lower ratios, sometimes below 50%. A well-tuned CDN for a standard media site should aim for 85-95% cache hit ratio.

What affects cache hit ratio

Several factors influence the ratio:

• TTL (Time to Live): Longer TTLs keep content cached longer, increasing hits. But stale content can be a problem for time-sensitive data. The trade-off requires careful per-object TTL tuning.
• Cache key uniqueness: Query parameters, cookies, or headers that vary per user can fragment the cache, creating many unique objects that are requested only once. Techniques like cache key normalization or ignoring irrelevant query parameters can help.
• Content popularity: The long tail of rarely accessed objects reduces overall hit ratio. Using an origin shield to consolidate miss traffic can improve the ratio for such content.
• Purge frequency: Frequent purges invalidate cache entries, forcing re-fetches. Batch purges or using surrogate keys can minimize impact.

Why it determines value

CDN pricing often separates bandwidth from request counts. A low cache hit ratio means more requests hit the origin, driving up both bandwidth and request costs. For a site doing 10 million requests per day, a difference of 10 percentage points in hit ratio could cost thousands of dollars per month in additional origin fees. More importantly, every cache miss adds origin latency, slowing down the user experience. Improving the ratio by just a few percent can yield significant performance and cost benefits.

Improving your cache hit ratio

Start by auditing your current cache configuration. Set appropriate Cache-Control headers on your origin responses. Use CDN-specific features like stale-while-revalidate to serve stale content while fetching fresh versions. For dynamic content, consider edge-side includes or worker-based caching. Monitor the ratio over time and correlate changes with deployments or configuration updates.

Cache invalidation, TTL, and purge strategies

Setting a TTL (time to live) is the simplest way to control how long a file stays in the CDN cache. You specify the TTL in seconds via the Cache-Control: max-age response header from your origin server. A common pattern is to set a long TTL for versioned assets like app.abc123.js (a year) and a short TTL for unversioned HTML (a few minutes). The CDN respects this header and revalidates the content when the TTL expires.

But TTL alone is not enough. When you deploy a new version of your site, you need to tell the CDN to throw away the old cached copies immediately. That is cache invalidation, also called a purge. Every major CDN provides an API for this. For example, Fastly's soft purge sends a Surrogate-Key header and allows you to purge by tag. Cloudflare's purge API accepts URLs, prefixes, or hostnames. Akamai uses CP codes and a REST API. The exact mechanism varies, but the concept is the same: you send a request to the CDN's control plane, and it marks the cached objects as stale across all edge nodes.

Purge strategies

There are three common strategies for keeping cache fresh:

1. Instant purge on deploy. Your CI/CD pipeline calls the CDN purge API after every deployment. This works well for small to medium sites. The downside: during the seconds it takes for the purge to propagate across all POPs, some users may still get the old content. Most CDNs claim propagation within 5 to 30 seconds.

2. Surrogate keys or cache tags. Instead of purging individual URLs, you tag related objects with a key (e.g., Surrogate-Key: product-123). When you update product 123, you purge that single key. This is more granular and faster than a full-site purge. Fastly and Cloudflare both support this pattern.

3. Stale-while-revalidate. This HTTP extension (RFC 5861) lets the CDN serve stale content while it fetches a fresh copy in the background. Set Cache-Control: stale-while-revalidate=86400 to allow serving stale content for up to a day while revalidating. This eliminates the latency spike that happens when a popular object expires and every request triggers an origin fetch.

Common pitfalls

One mistake is setting TTLs too short and defeating the purpose of the CDN. If your HTML TTL is 60 seconds and you have 10,000 requests per second, the CDN still hits your origin every 60 seconds. That may be acceptable, but you lose the benefit of edge caching. Another pitfall is forgetting to purge after a rollback. If you deploy a broken version and purge, then roll back, you must purge again. Otherwise the CDN still serves the broken version from its cache.

Finally, understand that purging is not instantaneous. CDNs use eventual consistency for cache invalidation. A purge request is acknowledged quickly, but the actual removal from all edge nodes can take tens of seconds. For critical updates (e.g., a pricing error), you may need to combine a purge with a temporary TTL reduction or a redirect.

Edge compute: running code at the edge with workers and functions

Traditional CDNs are great at caching static content, but what happens when you need to personalize a page, redirect a user based on geolocation, or authenticate an API request before it reaches your origin? Historically, you had to either push that logic back to your server or cobble together a fragile chain of reverse proxies. Edge compute changes that.

Edge compute platforms let you run JavaScript, WebAssembly, or other languages directly on the CDN's edge nodes. Instead of a request going all the way to your origin just to add a custom header or rewrite a URL, the edge node handles it in microseconds. The major players here are Cloudflare Workers (launched 2017), Fastly Compute@Edge (originally Terrarium, then Lucet, now based on WASM), and AWS Lambda@Edge (2017). Akamai has EdgeWorkers, and there are smaller entrants like Fly.io and Deno Deploy.

How edge workers differ from traditional serverless

A typical serverless function on AWS Lambda or Google Cloud Functions runs in a data center you choose. Cold starts can take hundreds of milliseconds. An edge worker runs in hundreds or thousands of locations simultaneously. When a user hits www.example.com, the nearest POP runs the worker. Cold starts are near zero because the runtime is tiny (often a V8 isolate, not a full container). Cloudflare Workers, for example, uses V8 isolates that start in under 5 milliseconds.

There is a tradeoff. Edge workers have strict limits on CPU time (e.g., 10-50ms per request on Cloudflare's free plan, 30 seconds on paid plans), memory (128 MB typical), and available APIs. You cannot open arbitrary TCP sockets or run long-lived processes. They are purpose-built for request/response transformations, not for heavy computation.

Common use cases

• Originless APIs: A worker that reads from a key-value store (like Cloudflare KV or Fastly's KV store) and returns JSON. No origin server needed.
• A/B testing: Route a percentage of traffic to a different origin or serve a different version of a page based on a cookie.
• Authentication at the edge: Validate a JWT token before the request hits your origin. Reject invalid tokens immediately, saving origin bandwidth.
• Image optimization: Resize, crop, and convert images on the fly based on query parameters (e.g., ?width=400&format=webp).
• Edge-side includes: Assemble a page from fragments cached independently.

A minimal example

Here is a Cloudflare Worker that adds a custom header and returns a response:

addEventListener('fetch', event => {
 event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
 const response = await fetch(request)
 const newHeaders = new Headers(response.headers)
 newHeaders.set('X-Edge-Processed', 'true')
 return new Response(response.body, {
 status: response.status,
 statusText: response.statusText,
 headers: newHeaders
 })
}

This intercepts every request, fetches the origin, adds a header, and returns the modified response. The origin never knows the header exists.

When not to use edge compute

If your logic requires database connections, large dependencies, or runs longer than the platform's timeout, stick with traditional serverless. Edge compute is a scalpel, not a sledgehammer. It excels at fast, stateless transformations close to the user.

TLS termination and Brotli compression at the edge

Every CDN edge node is a reverse proxy. When a user's TLS handshake reaches the edge, the CDN must terminate that connection, decrypt the request, inspect it, and then make a new connection to the origin server. This process is called TLS termination, and it is one of the most important performance optimizations a CDN provides.

Without a CDN, your origin server performs the TLS handshake itself. The handshake is computationally expensive. It involves asymmetric key exchange (ECDHE or RSA), certificate validation, and symmetric cipher negotiation. A single origin server at 1 Gbps can usually terminate about 10,000 to 20,000 new TLS connections per second (depends on cipher choice and hardware). A CDN with 200 edge POPs spreads that load. Each POP handles only the traffic from its region. The math works: 100,000 connections spread across 200 POPs is 500 per POP.

The CDN also holds the private key for your domain. This is the main security concern with TLS termination. The key must be stored in a hardware security module (HSM) or a secure enclave at each edge node. Providers like Cloudflare, Fastly, and AWS CloudFront support key pinning and hardware-backed key storage. Certificate management is automated. You upload your certificate once, and the CDN distributes it to every POP. The Let's Encrypt integration most CDNs offer means you can auto-provision TLS 1.3 certificates without touching a server.

Origin TLS re-encryption

After the edge terminates the user's TLS session, it can forward the request to your origin over a plaintext HTTP connection. This is common for low-traffic or LAN origins. But for production systems, you want the edge to open a new TLS tunnel to the origin. This is called re-encryption, or origin TLS. The CDN initiates a TLS 1.3 connection to your origin's HTTPS endpoint. It validates your origin certificate, and it can present its own client certificate for mutual TLS (mTLS). CloudFront calls this "Origin Protocol Policy" and defaults to HTTPS-only. Fastly calls it "Backend TLS." Always enable re-encryption. Without it, the traffic between the edge and your origin is plaintext across the public internet.

A warning: origin re-encryption adds latency. The edge must complete two TLS handshakes: one with the user and one with the origin. But this extra cost is typically 20 to 50 milliseconds, a small price for end-to-end encryption. You can eliminate the second handshake by enabling TLS session resumption (RFC 5077) on your origin. Many CDNs also support TLS False Start and 0-RTT (RFC 8446) for the user facing leg.

Brotli compression at the edge

Brotli (RFC 7932) is a compression algorithm developed by Google. It achieves 20-30 percent better compression ratios than gzip for the same content type. Brotli uses a predefined dictionary (for HTML, JavaScript, CSS) that makes it especially effective for small web assets. The cost is higher compression time. That cost is acceptable at a CDN edge because the edge pre-compresses static content once, stores it, and serves the compressed version to every subsequent user.

Most CDNs support Brotli compression at the edge. Cloudflare, Fastly, and Akamai all auto-compress text assets with Brotli when the client's Accept-Encoding header includes br. The client must support Brotli. All modern browsers do: Chrome since v49, Firefox since v44, Safari since v11. Internet Explorer 11 does not support Brotli. For users on IE, the CDN falls back to gzip automatically.

The configuration is straightforward:

# Nginx reverse proxy (origin side) - offload Brotli to CDN only if CDN cannot do it
brotli on;
brotli_types text/html text/css application/javascript;
brotli_comp_level 6;

# Most CDNs: enable Brotli in the dashboard/console
# Cloudflare: Dashboard > Speed > Optimization > Brotli = ON
# Fastly: VCL snippet to enable
if (req.http.Accept-Encoding ~ "br") {
 set req.http.Accept-Encoding = "br";
}

One nuance: Brotli compression level matters. Level 1 is fastest, level 11 is slowest but best compression. For CDN caching, use level 4 to level 6. Level 11 can take 20-30x longer to compress than gzip level 6, and the extra bytes saved are marginal for content that is not static. The CDN should compress at level 4 during the first byte of a cached response, store the compressed blob, and serve it. If your origin is doing Brotli before handing it to the CDN, check that your CDN does not re-compress at a higher level.

Cache key invalidation for Brotli works similarly to any other variant. The CDN treats a Brotli-compressed response as a separate cache entry from the gzip version, keyed on the Accept-Encoding header. When purging, you must invalidate both variants.

Origin shield and tiered caching for high-traffic sites

If every edge cache fetch misses and goes back to your origin server, you are not actually scaling. Tiered caching and origin shielding solve this. They are the architectural difference between a CDN that handles a spike and one that collapses under it.

A standard CDN topology is flat: each edge POP that does not have the object requests it directly from your origin. On a site with 50 active POPs, a single uncached asset generates 50 simultaneous requests to your server. That is called a thundering herd. It defeats the purpose of having a CDN in the first place.

How an origin shield works

An origin shield is a dedicated intermediate cache layer. Instead of every edge POP talking to your origin, they talk to the shield. The shield itself connects to your origin only when it does not have the object. Cloudflare calls this Tiered Cache (formerly Argo Tiered Cache). Fastly has shielding. Akamai has parent caches. They all do the same thing: reduce the number of connections to your origin to one per object regardless of how many edge POPs request it.

To enable shielding on Fastly, you configure a shield POP geographic to your origin. On Fastly, the shield POP is set in the VCL by specifying a shield. For example:

# In your Fastly VCL boilerplate
set req.backend = F_origin;

# The shield POP assignment happens via the Fastly web UI for
# the service, selecting a shield region such as "us-east-1".

Tiered caching with multiple layers

Larger providers add a second tier between edge and shield. Cloudflare uses a two tier system: Tier 1 cache at the edge POP and Tier 2 cache in a regional hub. If a Tier 1 POP misses, it checks the Tier 2 hub. Only if both miss does the request go to the origin. This keeps origin traffic near zero for popular objects.

The configuration on Cloudflare is straightforward under the Caching tab > Tiered Cache. You toggle it on. Cloudflare automatically selects the nearest Tier 2 hub based on your zone configuration.

When tiered caching backfires

Tiered caching adds latency on a cache miss because the object must travel through an extra hop before reaching the end user. For sites with a very high cache hit ratio (above 95 percent), the extra hop on misses is negligible because misses are rare. For sites with low hit ratios or rapidly changing dynamic content, the extra hop can hurt. Measure your hit ratio before enabling tiered caching.

A better approach for mixed workloads is to separate static and dynamic routes. Route static assets through the tiered cache. Route API or authenticated content directly to origin with a shorter TTL. Use separate hostnames or path rules in your CDN configuration.

Picking a CDN: pricing models, POP count, and feature comparison

Choosing a CDN is not a one size fits all decision. The right provider for a personal blog is almost certainly wrong for a streaming video platform. You need to match your traffic patterns, budget, and technical requirements to a specific mix of features. This section walks through the three major axes: how you pay, where the edges are, and what the service actually does.

Pricing models

Most CDNs charge by the gigabyte of data transfer out. Cloudflare offers a free tier (up to 1 TB/month) and then charges per GB above that, with volume discounts. Akamai and Fastly publish no list prices; you negotiate a contract with committed monthly traffic. Amazon CloudFront and Google Cloud CDN bill per request plus per GB, with regional pricing differences. A few providers, like BunnyCDN, charge a flat per GB rate regardless of region. Watch for hidden costs: purge requests (Fastly charges per purge call after the first 10,000), origin fetch fees, and premium support add-ons. If your site serves 90 percent of traffic to North America and Europe, a provider with cheap US/EU rates but expensive Asia pricing might still be fine. If you have a global audience, look for providers that flatten regional pricing (Cloudflare, BunnyCDN, or negotiated contracts with Akamai).

POP count and coverage

More POPs do not automatically mean faster performance. What matters is POP placement relative to your audience. Cloudflare claims 330 cities in 120 countries. Akamai has about 4,100 locations in 135 countries, many inside ISP networks, which reduces last mile latency. Fastly operates about 150 POPs but they are all connected to a single high speed backbone (Fastly claims 40 Tbps). A small network can be fast if its POPs are in the right places. Check the provider's POP list against your users' locations. If you serve a lot of traffic in Southeast Asia or South America, verify coverage there. Some providers have excellent US and European coverage but thin presence elsewhere. You can test this yourself by running curl from multiple global endpoints (use something like CatchPoint or Checkly) and comparing the latency to each provider's edge.

Feature comparison

The high level features every CDN offers are: HTTP/2, TLS/SSL termination, Gzip and Brotli compression, cache purge, and DDoS protection. Differences emerge in the details. Fastly and Cloudflare Workers let you run custom code at the edge via JavaScript or WebAssembly, which lets you do A/B testing, rewrite requests, or even serve a full application without a traditional origin server. Akamai offers similar edge compute through EdgeWorkers and EdgeKV for key value storage. If you need real time cache invalidation, Fastly purges in under 150 milliseconds; Cloudflare takes a few seconds. For origin shielding, Cloudflare has Argo Tiered Cache, Fastly has shielding at the POP level, Akamai has a dedicated parent tier. Some providers support image optimization at the edge (Cloudflare, ImageEngine, Akamai Image & Video Manager). If you serve API traffic, look for WebSocket support: Fastly, Cloudflare, and Akamai all support it, but some budget providers do not. Finally, examine the dashboard and API. A good RESTful API for purging, reloading configs, and fetching real time logs is worth more than a pretty GUI.

There is no single best CDN. For a low traffic blog with a tight budget, the free Cloudflare plan is hard to beat. For a high volume video streaming service with complex caching rules, a negotiated contract with Akamai or Fastly makes more sense. For a developer who wants to run code at the edge, Fastly or Cloudflare Workers are the natural picks. Map your non negotiable requirements against the feature matrix of each provider, run real world benchmarks, and choose the platform that matches your actual traffic, not someone else's.