What Is a CDN? How Content Delivery Networks Work

Last Updated: October 2026

A CDN (Content Delivery Network) is a geographically distributed network of servers designed to deliver web content to users as quickly and reliably as possible. Instead of every user request traveling across the globe to a single origin server, a CDN caches copies of your content — images, stylesheets, JavaScript, videos, fonts, and even API responses — on edge servers located in data centers around the world. When a user visits your site, the CDN serves the content from the nearest edge server, dramatically reducing latency and improving the user experience.

CDNs have become essential infrastructure for the modern web. The majority of internet traffic today flows through CDNs, from streaming video (Netflix uses its own CDN called Open Connect) to social media feeds, e-commerce sites, news outlets, and even small personal blogs. In this guide, we will explain how CDNs work under the hood, cover routing mechanisms, caching strategies, SSL/TLS integration, compare major providers, and help you decide when and how to implement a CDN. You can use our DNS Lookup tool to verify your CDN's DNS configuration is resolving correctly.

How CDNs Work: The Fundamentals

Edge Servers and Points of Presence (PoPs)

The core infrastructure of a CDN consists of edge servers deployed in data centers called Points of Presence (PoPs) located in cities and network exchange points around the world. A major CDN like Cloudflare operates over 300 PoPs across 100+ countries; Akamai operates over 4,000 PoPs.

Each PoP contains servers with high-speed storage (often NVMe SSDs) and substantial RAM for caching frequently accessed content. When a user in Tokyo requests a resource from a website whose origin server is in Virginia, the CDN serves the cached content from a PoP in Tokyo instead of routing the request across the Pacific Ocean and back. The physical distance reduction translates directly into lower latency — a request that might take 200ms to the origin can be served in 5–15ms from a nearby PoP.

Origin Server

The origin server is your actual web server (or hosting provider) where the original, authoritative copies of your content live. The CDN sits between users and the origin. When the CDN's edge server does not have a cached copy of a requested resource (a cache miss), it fetches the resource from the origin, serves it to the user, and stores it in its local cache for subsequent requests. This fetch-from-origin step is sometimes called an origin pull.

CDN Routing: How Requests Reach the Right Edge Server

CDNs use two primary mechanisms to route user requests to the optimal edge server: anycast routing and DNS-based routing.

Anycast Routing

Anycast is a network addressing method where the same IP address is advertised from multiple locations around the world. When a user sends a request to an anycast IP, the internet's BGP (Border Gateway Protocol) routing automatically directs the request to the nearest location advertising that IP, based on network topology (fewest hops, lowest latency path).

Cloudflare is the most prominent example of an anycast CDN. When you use Cloudflare, your domain resolves to Cloudflare's anycast IP addresses, and BGP routing ensures each user reaches the closest Cloudflare PoP automatically. Anycast has a major additional benefit: it provides inherent DDoS resilience because attack traffic is naturally distributed across all PoPs rather than concentrated on a single server.

DNS-Based Routing

DNS-based routing uses intelligent DNS resolution to direct users to different edge server IPs based on their geographic location, network conditions, or server health. When a user's DNS resolver queries the CDN's authoritative DNS server, the DNS server examines the resolver's IP address (or the EDNS Client Subnet if available) to estimate the user's location, then returns the IP address of the optimal edge server for that user.

AWS CloudFront and Akamai primarily use DNS-based routing. This approach allows for more granular control — the CDN can factor in real-time server load, health checks, and latency measurements when choosing which edge server IP to return. The trade-off is that DNS resolution adds a step (and a small amount of latency) compared to anycast's instant network-level routing. You can observe this in action by running a DNS Lookup for a CloudFront distribution from different locations — you will see different IP addresses returned.

How CDN Caching Works

Caching is the heart of a CDN's value proposition. By storing copies of resources on edge servers, the CDN eliminates the need for repeated round trips to the origin server.

Cache Hit vs. Cache Miss

When a user requests a resource, the edge server checks its local cache:

• Cache Hit: The resource is found in the cache and served directly to the user. This is the ideal scenario — fastest response, no origin load.
• Cache Miss: The resource is not in the cache (either it was never cached or it has expired). The edge server fetches it from the origin, serves it to the user, and stores it locally.
• Stale: The cached copy exists but has expired. The edge server may serve the stale copy while revalidating with the origin in the background (stale-while-revalidate) or may block until revalidation completes.

CDN performance is often measured by cache hit ratio — the percentage of requests served from cache versus fetched from origin. A well-configured CDN typically achieves 85–99% cache hit ratios for static content.

Cache-Control Headers

The origin server controls caching behavior through HTTP Cache-Control headers. These headers tell the CDN (and browsers) how to cache each resource:

• Cache-Control: public, max-age=86400 — The resource can be cached by any cache (CDN, browser) for 86,400 seconds (24 hours).
• Cache-Control: private, max-age=0 — The resource should not be cached by shared caches (CDNs) but may be cached by the user's browser. Used for personalized content.
• Cache-Control: no-store — The resource must not be cached at all. Used for sensitive data (banking pages, authentication tokens).
• Cache-Control: s-maxage=3600 — Overrides max-age specifically for shared caches (CDNs), allowing different cache durations for CDN vs. browser.
• Cache-Control: stale-while-revalidate=60 — Allows the CDN to serve a stale copy for up to 60 seconds while fetching a fresh copy from the origin in the background.

TTL (Time to Live)

The TTL determines how long a cached resource remains valid before the CDN considers it stale and either revalidates or re-fetches it from the origin. TTL is derived from Cache-Control headers (max-age, s-maxage) or can be overridden in CDN configuration. Choosing the right TTL is a balance:

• Long TTL (hours/days): Higher cache hit ratio, less origin load, but slower propagation of content updates. Ideal for assets that rarely change (fonts, compiled CSS/JS with content hashes in filenames).
• Short TTL (seconds/minutes): Content updates propagate faster, but more origin fetches, lower cache hit ratio. Suitable for frequently updated content like news articles or API responses.
• TTL of 0: The CDN revalidates with the origin on every request but can still serve cached content if the origin responds with 304 Not Modified. This provides freshness with conditional caching benefits.

Cache Purging (Invalidation)

When you need to update cached content immediately (rather than waiting for TTL expiration), CDNs provide cache purge (invalidation) mechanisms:

• Purge by URL: Remove a specific URL from all edge server caches. Example: purge /images/logo.png after updating the logo.
• Purge by path/prefix: Remove all URLs matching a pattern. Example: purge /blog/* after a bulk content update.
• Purge everything: Clear the entire cache across all edge servers. Use sparingly — this causes a thundering herd of requests to the origin.
• Cache tags/surrogate keys: Tag cached resources with custom labels and purge by tag. Example: tag all product images with product-123 and purge that tag when the product is updated. Fastly and Cloudflare support this advanced feature.

Benefits of Using a CDN

Reduced Latency

The primary benefit of a CDN is lower latency. By serving content from the nearest edge server, a CDN can reduce page load times by 50% or more for users far from the origin server. This directly impacts user experience, SEO rankings (Core Web Vitals), and conversion rates. Studies consistently show that every 100ms reduction in page load time increases conversions.

Bandwidth Savings

CDN caching reduces the amount of data the origin server must transfer. Since edge servers handle the majority of requests, origin bandwidth consumption drops significantly — often by 60–90%. This reduces hosting costs and allows the origin to be provisioned with less bandwidth.

DDoS Protection

CDNs absorb distributed denial-of-service attacks by spreading traffic across their entire global network. An attack that might overwhelm a single origin server is diluted across hundreds of PoPs, each absorbing a fraction of the traffic. Major CDNs can absorb attacks exceeding 1 Tbps. They also provide application-layer DDoS protection through rate limiting, challenge pages (CAPTCHAs), IP reputation filtering, and Web Application Firewalls.

SSL/TLS Offloading

TLS encryption and decryption are CPU-intensive operations. CDNs handle TLS termination at the edge, offloading this work from your origin server. The CDN manages certificate deployment, supports the latest TLS versions (TLS 1.3), and can optionally re-encrypt the connection between the CDN and origin. For more on SSL/TLS, see our What Is SSL/TLS guide.

High Availability and Redundancy

If your origin server goes down, a CDN can continue serving cached content to users (depending on your cache configuration). This provides a degree of fault tolerance. Additionally, if one PoP experiences issues, the CDN automatically routes traffic to the next nearest healthy PoP, ensuring continuous availability.

CDN and DNS Interaction

CDNs rely heavily on DNS for routing, and understanding this interaction is critical for proper configuration:

• CNAME setup: Many CDNs require you to create a CNAME record pointing your domain (e.g., assets.example.com) to the CDN's hostname (e.g., d1234.cloudfront.net). DNS resolvers follow the CNAME chain to reach the CDN's IP.
• NS delegation: Some CDNs (like Cloudflare) require you to delegate your domain's DNS entirely by changing your name servers to the CDN's name servers. This gives the CDN full control over DNS resolution and enables features like automatic SSL and proxied DNS.
• DNS TTL: CDN DNS records should have relatively short TTLs (60–300 seconds) to allow quick failover if a PoP goes offline. Long DNS TTLs can cause users to be stuck connecting to a non-responsive PoP.
• EDNS Client Subnet: Some DNS resolvers send the client's subnet information to the CDN's authoritative DNS server, allowing more accurate geographic routing decisions.

Use our DNS Lookup tool to verify that your domain's DNS records are correctly pointing to your CDN and to check propagation after configuration changes.

CDN and SSL/TLS

SSL/TLS configuration is one of the most important aspects of CDN setup. CDNs support several encryption modes:

• Flexible SSL: The connection between the user and the CDN is encrypted (HTTPS), but the connection between the CDN and the origin is unencrypted (HTTP). This is easy to set up but not fully secure — traffic between CDN and origin could be intercepted.
• Full SSL: Both connections are encrypted. The CDN verifies that the origin has a valid SSL certificate (but may accept self-signed certificates). This provides end-to-end encryption.
• Full (Strict) SSL: Both connections are encrypted, and the CDN requires the origin to have a valid, trusted SSL certificate (not self-signed). This is the most secure option and is recommended for production environments.
• Origin certificates: Some CDNs (like Cloudflare) provide free origin certificates that are trusted only by the CDN itself, simplifying origin SSL setup while maintaining Full (Strict) encryption.

CDNs also provide automatic HTTPS redirects, HSTS (HTTP Strict Transport Security) headers, automatic certificate renewal, and support for modern TLS features like TLS 1.3, OCSP stapling, and encrypted SNI.

Major CDN Providers

Cloudflare

Cloudflare is the most widely used CDN, serving a significant percentage of all internet traffic. It uses anycast routing with 300+ PoPs worldwide. Cloudflare's free tier includes CDN caching, DNS hosting, basic DDoS protection, free SSL certificates, and a rules engine. Paid plans add advanced features like WAF, image optimization, Argo Smart Routing (which finds the fastest network paths), and Workers (serverless compute at the edge). Cloudflare is unique in requiring NS delegation, giving it full DNS control over your domain.

AWS CloudFront

Amazon CloudFront is AWS's CDN service, tightly integrated with the AWS ecosystem (S3, EC2, Lambda@Edge, Route 53). It uses DNS-based routing with 450+ PoPs across 90+ cities. CloudFront supports custom SSL certificates (via AWS Certificate Manager), real-time logging, origin failover groups, and Lambda@Edge for serverless compute at the edge. Pricing is pay-as-you-go based on data transfer and requests. CloudFront is the default choice for AWS-hosted applications.

Akamai

Akamai is the oldest and one of the largest CDN providers, operating the most extensive edge network with 4,000+ PoPs in 130+ countries. Akamai specializes in enterprise-grade CDN services and is used by many of the world's largest media companies, banks, and e-commerce platforms. It offers advanced features like adaptive media delivery, edge compute, bot management, and API acceleration. Akamai is typically more expensive than alternatives and is positioned for large enterprises with complex requirements.

Fastly

Fastly differentiates itself with real-time cache purging (content is purged globally in under 150ms) and its Compute@Edge platform for running custom logic at edge servers. Fastly uses Varnish-based caching and provides granular cache control through surrogate keys, instant purge APIs, and VCL (Varnish Configuration Language) for custom cache rules. It is popular among technology companies, media outlets, and e-commerce platforms that need fine-grained control over caching behavior.

Google Cloud CDN

Google Cloud CDN leverages Google's global network infrastructure (the same network that serves Google Search, YouTube, and Gmail). It integrates natively with Google Cloud Load Balancing, Cloud Storage, and Compute Engine. Google Cloud CDN uses anycast with Google's premium network tier and supports cache invalidation, custom cache keys, and Cloud Armor for DDoS protection. It is the natural choice for applications hosted on Google Cloud Platform.

CDN for Static vs. Dynamic Content

Static Content (Ideal for CDN)

Static content — files that do not change between requests — is the ideal use case for CDN caching. This includes:

• Images (JPEG, PNG, WebP, AVIF, SVG)
• Stylesheets (CSS)
• JavaScript bundles
• Fonts (WOFF2, WOFF, TTF)
• Videos and audio files
• PDF documents and downloadable files
• Static HTML pages (pre-rendered/SSG pages)

For static content, use long TTLs (days or weeks) combined with content-based file naming (cache busting via hashes in filenames, e.g., app.a3b2c1.js). When the content changes, the filename changes, naturally busting the cache without requiring a purge.

Dynamic Content

Dynamic content is generated per request (e.g., personalized dashboards, search results, API responses with user-specific data). Caching dynamic content at the CDN is more complex and requires careful strategy:

• Cache with short TTLs: Cache API responses for seconds or minutes. Even a 5-second cache can eliminate massive spikes (if 1,000 users request the same endpoint in 5 seconds, only one request hits the origin).
• Cache by query parameters: Configure the CDN to treat different query strings as different cache keys (e.g., /search?q=cats and /search?q=dogs are cached separately).
• Edge compute: Use platforms like Cloudflare Workers, Lambda@Edge, or Fastly Compute@Edge to run server-side logic at the edge, generating dynamic responses without hitting the origin.
• Stale-while-revalidate: Serve slightly stale content while fetching a fresh copy in the background, providing the speed of caching with near-real-time freshness.

When You Need a CDN

A CDN is beneficial in these scenarios:

• Global audience: If your users are spread across multiple continents, a CDN is essential for consistent performance. Without one, users far from your origin server experience significantly higher latency.
• High traffic volume: CDNs absorb the majority of requests, protecting your origin from being overwhelmed during traffic spikes (product launches, viral content, sales events).
• Media-heavy content: Sites with many images, videos, or downloadable files benefit greatly from CDN caching and bandwidth savings.
• SEO and Core Web Vitals: Google uses page speed as a ranking factor. CDNs improve Largest Contentful Paint (LCP), Time to First Byte (TTFB), and Cumulative Layout Shift (CLS) by serving content faster.
• DDoS vulnerability: Any public-facing website can be targeted by DDoS attacks. A CDN provides baseline protection at no extra cost.
• Cost optimization: CDN bandwidth is often cheaper than origin bandwidth, especially with providers like Cloudflare that offer unmetered bandwidth on all plans.

Measuring CDN Performance

To verify your CDN is working correctly and delivering the expected performance benefits, use these methods:

• Response headers: Check for CDN-specific headers like CF-Cache-Status: HIT (Cloudflare), X-Cache: Hit from cloudfront (CloudFront), or X-Served-By (Fastly) to confirm content is being served from cache.
• TTFB (Time to First Byte): Measure the time between sending a request and receiving the first byte of the response. CDN-cached content should have TTFB under 50ms for nearby PoPs.
• Cache hit ratio: Monitor the percentage of requests served from cache vs. origin. Most CDN dashboards provide this metric. Target 85%+ for static-heavy sites.
• Latency from multiple locations: Use our Ping & Traceroute tool to measure latency from different geographic locations to your CDN-fronted domain.
• Real User Monitoring (RUM): Tools like Google PageSpeed Insights, Lighthouse, and WebPageTest measure actual user-perceived performance metrics including LCP, FID, and CLS.
• CDN analytics dashboard: All major CDNs provide analytics showing requests served, bandwidth saved, cache hit ratio, threat mitigation, and geographic distribution of traffic.

CDN Configuration Best Practices

• Set proper Cache-Control headers at the origin: The CDN respects your origin's caching directives. If your origin sends Cache-Control: no-store, the CDN will not cache the resource regardless of CDN-side settings.
• Use content-hashed filenames for static assets: Instead of style.css, use style.a3b2c1.css. When the content changes, the hash changes, creating a new cache key. This allows long TTLs without stale content issues.
• Configure custom cache keys carefully: Avoid including unnecessary query parameters or headers in cache keys, as this fragments the cache and reduces hit ratio.
• Use Full (Strict) SSL: Always encrypt the connection between CDN and origin for true end-to-end encryption.
• Enable compression: Ensure Brotli and gzip compression are enabled at the CDN edge for text-based resources (HTML, CSS, JS, JSON, SVG).
• Set up origin failover: Configure a secondary origin server so the CDN can automatically switch if the primary origin is unreachable.
• Monitor cache hit ratio: Regularly review your CDN's cache hit ratio and investigate if it drops. Common causes include misconfigured Cache-Control headers, excessive cache key variation, and low-traffic pages that rarely get cached.

Frequently Asked Questions

What is a CDN in simple terms?

A CDN is a global network of servers that caches and delivers web content from locations close to each user. Instead of every request traveling to a single origin server, the CDN serves cached content from the nearest edge server, reducing load times and improving reliability.

How does a CDN reduce latency?

A CDN caches content on edge servers in data centers (PoPs) around the world. When a user requests a resource, the CDN serves it from the nearest PoP. Since data travels a shorter physical distance, round-trip time is dramatically lower — for example, 10ms from a local PoP vs. 200ms to a distant origin server.

What is the difference between anycast and DNS-based CDN routing?

Anycast assigns the same IP to multiple edge servers; the network routes each request to the closest one via BGP. DNS-based routing resolves the domain to different IPs based on the user's location. Cloudflare uses anycast; AWS CloudFront uses DNS-based routing. Both achieve the same goal of directing users to nearby servers.

How does CDN caching work?

When a resource is requested, the edge server checks its cache. On a cache hit, it serves the cached copy immediately. On a cache miss, it fetches from the origin, serves the response, and caches it. Cache duration is controlled by Cache-Control headers and TTL values set by the origin server.

Can a CDN protect against DDoS attacks?

Yes. CDNs distribute traffic across hundreds of global PoPs, absorbing attacks across the entire network. Major CDNs can handle attacks exceeding 1 Tbps. They also provide rate limiting, IP reputation filtering, and WAFs for application-layer protection.

What is the difference between a CDN and web hosting?

Web hosting is where your site's files and application logic live (the origin server). A CDN is a caching and delivery layer that sits in front of your origin. The CDN does not replace hosting — it supplements it by caching static content at edge locations to reduce load and speed up delivery.

Do I need a CDN for my website?

You benefit from a CDN if you serve users in multiple regions, have significant static content, experience traffic spikes, or need DDoS protection. Free CDN tiers (like Cloudflare's) make it worthwhile for almost any site. Small local sites with minimal traffic may not see dramatic improvement.

How does a CDN handle SSL/TLS?

CDNs terminate TLS at the edge (handling encryption/decryption for the user's connection) and optionally re-encrypt traffic to the origin. Modes range from Flexible SSL (edge only) to Full (Strict) SSL (end-to-end with validated origin certificate). CDNs also provide free certificates, automatic HTTPS redirects, and TLS 1.3 support. For details, see our SSL/TLS guide.