CDN (Content Delivery Network): The Complete Guide to Faster Content Delivery

CDN (Content Delivery Network): The Complete Guide to Faster Content Delivery

A Content Delivery Network (CDN) is a geographically distributed network of proxy servers and data centers designed to deliver web content to users with high availability and performance. Instead of every request hitting a single origin server, CDNs cache and serve content from edge locations closest to the end user, dramatically reducing latency, bandwidth costs, and server load.

Modern web applications rely heavily on CDNs. Companies like Netflix, Amazon, and Facebook serve billions of requests daily through CDN infrastructure. Whether you serve static assets, stream video, or deliver dynamic API responses, understanding CDN architecture is essential for any software engineer building performant systems.

How a CDN Works

At its core, a CDN operates on a simple principle: move content closer to the user. Here is the step-by-step flow of a typical CDN request:

1. DNS Resolution: When a user requests cdn.example.com/style.css, DNS resolves the domain to the nearest CDN edge server using Anycast routing or geo-based DNS.
2. Edge Cache Check: The edge server checks its local cache for the requested resource.
3. Cache Hit: If the resource exists and has not expired, the edge server returns it directly. This is the fastest path, often under 10ms.
4. Cache Miss: If the resource is not cached, the edge server fetches it from the origin server (or a mid-tier cache), stores a copy locally, and then serves it to the user.
5. Subsequent Requests: Future requests from nearby users are served from the edge cache until the TTL (Time to Live) expires.

Edge Locations and Points of Presence (PoPs)

CDN providers maintain hundreds of Points of Presence worldwide. Each PoP contains multiple edge servers that cache content. Major providers distribute PoPs strategically:

The choice of provider depends on your existing infrastructure, budget, and specific requirements like real-time purging or edge compute capabilities. Test your CDN performance using network diagnostic tools to measure latency from different regions.

Push CDN vs Pull CDN

CDNs broadly fall into two architectural models based on how content reaches the edge:

Pull CDN

In a pull CDN, edge servers fetch content from the origin on-demand when a cache miss occurs. This is the most common model used by CloudFront, Cloudflare, and most modern providers.

• Pros: Simple setup, no manual upload required, automatic cache population, works well for frequently accessed content.
• Cons: First request to each edge is slow (cache miss), origin must handle burst traffic on cache expiry.
• Best for: Websites, APIs, and applications with organic traffic patterns.

Push CDN

In a push CDN, you proactively upload content to the CDN before users request it. The CDN stores your content and serves it without ever contacting the origin.

• Pros: No cache misses, origin server is never hit, predictable performance.
• Cons: Requires manual content management, storage costs, must handle updates/deletions yourself.
• Best for: Large static files (videos, software downloads), content that rarely changes, pre-rendered pages.

Most real-world CDN setups use a hybrid approach, employing pull for dynamic and frequently-changing content while pushing large, static assets directly.

Caching Strategies and Cache-Control Headers

Effective caching is the backbone of CDN performance. The HTTP Cache-Control header dictates how CDNs (and browsers) cache your content. Understanding these directives is critical:

Cache-Control: public, max-age=31536000, immutable

Cache-Control: no-cache

Cache-Control: private, no-store

Cache-Control: public, s-maxage=3600, max-age=60, stale-while-revalidate=86400

A common production strategy combines content hashing with aggressive caching. Static assets get hashed filenames and year-long cache TTLs, while HTML pages use short TTLs or stale-while-revalidate.

Cache Invalidation

Cache invalidation is famously one of the two hard problems in computer science. When you deploy new content, stale cached versions may persist across edge locations. Here are the primary invalidation strategies:

1. TTL-Based Expiry

Set appropriate max-age or s-maxage values and let caches expire naturally. Simple but imprecise — users may see stale content until TTL expires.

2. Cache Purging (Instant Invalidation)

Explicitly remove content from CDN caches. Most providers support this via API:

# AWS CloudFront — Invalidate specific paths
aws cloudfront create-invalidation \
  --distribution-id E1A2B3C4D5E6F7 \
  --paths "/css/*" "/js/app.js" "/index.html"

# Cloudflare — Purge specific URLs
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/styles.css","https://example.com/app.js"]}'

# Fastly — Instant purge by surrogate key
curl -X POST "https://api.fastly.com/service/{service_id}/purge/product-page" \
  -H "Fastly-Key: {api_token}"

3. Cache Busting with Versioned URLs

The most reliable approach: change the URL when content changes. Build tools like Webpack and Vite generate hashed filenames automatically:

<link rel="stylesheet" href="/css/styles.a8f3e2b1.css">
<script src="/js/bundle.7c9d4e5f.js"></script>

Since the URL itself changes on each deploy, there is no stale cache to invalidate. Combined with immutable caching, this delivers the best performance with zero staleness risk.

4. Surrogate Keys (Tag-Based Purging)

Advanced CDNs like Fastly support tagging cached objects with surrogate keys. When a product updates, you purge by tag instead of individual URLs, invalidating all related pages instantly.

CloudFront Configuration Example

Here is a practical AWS CloudFront distribution configuration using a CloudFormation template that sets up a CDN for a static website with an S3 origin:

Resources:
  CDNDistribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Origins:
          - Id: S3Origin
            DomainName: my-bucket.s3.amazonaws.com
            S3OriginConfig:
              OriginAccessIdentity: origin-access-identity/cloudfront/E1X2Y3Z4
        DefaultCacheBehavior:
          TargetOriginId: S3Origin
          ViewerProtocolPolicy: redirect-to-https
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
          Compress: true
          AllowedMethods:
            - GET
            - HEAD
          CachedMethods:
            - GET
            - HEAD
        PriceClass: PriceClass_100
        Enabled: true
        DefaultRootObject: index.html
        HttpVersion: http2and3

Cloudflare Page Rules and Cache Configuration

Cloudflare provides flexible caching rules. Here is an example using Cloudflare Workers to set custom cache behavior at the edge:

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

async function handleRequest(request) {
  const url = new URL(request.url);

  const cacheSettings = {
    "/api/": { cacheTtl: 0 },
    "/static/": { cacheTtl: 86400, cacheEverything: true },
    "/": { cacheTtl: 300, cacheEverything: true }
  };

  const matchedPath = Object.keys(cacheSettings)
    .find(path => url.pathname.startsWith(path));

  const cfOptions = matchedPath ? cacheSettings[matchedPath] : {};

  return fetch(request, { cf: cfOptions });
}

Nginx Origin Server Cache Headers

Your origin server must send the correct headers for the CDN to cache effectively. Here is a typical Nginx configuration:

server {
    listen 443 ssl http2;
    server_name example.com;

    location ~* \.(js|css|woff2|png|jpg|svg|ico)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        add_header Vary "Accept-Encoding";
    }

    location ~* \.html$ {
        add_header Cache-Control "public, s-maxage=300, max-age=60, stale-while-revalidate=3600";
    }

    location /api/ {
        add_header Cache-Control "private, no-store";
    }
}

Performance Benefits of Using a CDN

CDNs deliver measurable improvements across multiple dimensions:

• Reduced Latency: Content served from edge locations 10-50ms away instead of 200-500ms from a distant origin. This directly improves Core Web Vitals like LCP and FCP.
• Bandwidth Savings: CDNs handle 60-90% of traffic, reducing origin bandwidth costs significantly. Most CDNs also apply Brotli or Gzip compression at the edge.
• Origin Offload: With cache hit ratios of 85-99%, your origin servers handle a fraction of total traffic, allowing smaller and cheaper infrastructure.
• High Availability: If one edge location fails, DNS routes users to the next closest PoP. Many CDNs also serve stale content when the origin is down.
• DDoS Protection: CDN networks absorb volumetric attacks across their distributed infrastructure, preventing them from reaching your origin.
• TLS Termination at Edge: SSL handshakes happen at the nearest edge server, eliminating the round-trip penalty of TLS negotiation with a distant origin.

Use developer tools and analyzers to benchmark your site performance before and after enabling a CDN.

Real-World CDN Examples

Netflix

Netflix operates Open Connect, a custom CDN with appliances embedded directly in ISP networks. During peak hours, Open Connect serves over 95% of Netflix traffic without hitting centralized servers, delivering 4K streams with minimal buffering worldwide.

Shopify

Shopify uses Cloudflare for its storefront CDN, caching product pages at the edge. Dynamic content like cart and checkout bypasses the cache using Cache-Control: private, while static product images and theme assets get year-long TTLs with hashed URLs.

GitHub

GitHub serves repository assets, avatars, and raw file content through Fastly. Surrogate-key-based purging lets GitHub instantly invalidate cached content when a user pushes new code, while still maintaining aggressive caching for unchanged files.

News Websites

Major news outlets use stale-while-revalidate to serve breaking news pages. Users see the cached version instantly while the CDN fetches the updated page in the background. This keeps pages fast even under massive traffic spikes during major events.

CDN Anti-Patterns to Avoid

• Caching authenticated content: Never cache responses containing user-specific data with public headers. One user could see another user's data.
• Ignoring Vary headers: If your origin returns different content based on Accept-Encoding or Accept-Language, include the Vary header or risk serving wrong content.
• Wildcard invalidation abuse: Purging /* on every deploy defeats the purpose of caching. Use versioned URLs or targeted purges instead.
• Setting no cache headers: Without explicit cache-control headers, CDN behavior varies by provider and may produce unpredictable results.

Frequently Asked Questions

What is the difference between a CDN and a load balancer?

A CDN caches and serves content from geographically distributed edge servers to reduce latency. A load balancer distributes incoming traffic across multiple origin servers within a single data center or region. They solve different problems: CDNs optimize for geographic proximity and caching, while load balancers optimize for server utilization and redundancy. In practice, most architectures use both — a CDN at the edge and load balancers in front of origin servers. Explore related networking concepts with our API and network tools.

How do I choose between CloudFront and Cloudflare?

Choose CloudFront if your infrastructure is already on AWS. It integrates natively with S3, Lambda@Edge, and other AWS services, and data transfer between CloudFront and AWS origins is free. Choose Cloudflare if you want a generous free tier, built-in WAF and DDoS protection on all plans, and a provider-agnostic CDN. Cloudflare also excels at DNS performance with its Anycast network. For enterprise-scale media streaming, consider Akamai or Fastly.

Can a CDN cache dynamic API responses?

Yes, with careful configuration. API responses that are identical for all users (public catalogs, search results, product listings) can be cached with short TTLs using s-maxage. Combine this with stale-while-revalidate to keep responses fast while updating in the background. However, never cache authenticated or user-specific API responses at the CDN layer. Use the Vary header or Cache-Control: private for personalized content.

How does cache invalidation work across all edge locations?

When you issue a purge request, the CDN propagates the invalidation command to all edge locations globally. CloudFront typically completes invalidation within 60-120 seconds across all PoPs. Cloudflare claims under 30 seconds globally. Fastly offers instant purging in under 150 milliseconds using their surrogate key system. Note that invalidation does not guarantee the content is removed — it marks it as stale, so the next request triggers a fresh fetch from the origin.

Does using a CDN improve SEO rankings?

Indirectly, yes. Google uses Core Web Vitals as ranking signals, and CDNs directly improve metrics like Largest Contentful Paint (LCP), First Contentful Paint (FCP), and Time to First Byte (TTFB). Faster page loads also reduce bounce rates, which positively influences search rankings. Additionally, CDNs provide HTTPS by default, and Google favors HTTPS pages. While a CDN alone will not guarantee higher rankings, it removes performance-related penalties that can hurt your position. Analyze your site metrics with our developer tools.