What is a CDN (Content Delivery Network)?

A CDN is a geographically distributed network of proxy servers and data centers designed to deliver web content—HTML, CSS, JavaScript, images, video—from the server physically closest to the requesting user. The concept dates back to Akamai's founding in 1998, but modern CDNs like Cloudflare, Fastly, and AWS CloudFront now handle an estimated 60%+ of all internet traffic. By caching assets at edge locations (called Points of Presence, or PoPs), a CDN typically reduces Time to First Byte (TTFB) by 50–300ms compared to a single-origin setup. This directly impacts Core Web Vitals—specifically Largest Contentful Paint (LCP), where Google's "good" threshold is 2.5 seconds or less. We use CDNs on virtually every project we ship, whether it's a static Astro site or a dynamic Next.js app with ISR.

How it works

When a user requests a resource, DNS resolution routes the request to the nearest CDN edge node instead of the origin server. Here's the flow:

First request (cache MISS): The edge node doesn't have the asset cached. It fetches from the origin server, serves it to the user, and stores a copy locally.
Subsequent requests (cache HIT): The edge node serves the cached copy directly, skipping the origin entirely.
Cache invalidation: When content changes, the origin signals the CDN to purge stale assets—either via TTL expiration, cache tags, or manual purge APIs.

Most CDNs respect standard HTTP cache headers:

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

For a Next.js project using Vercel's built-in CDN, static assets under /_next/static/ get this header automatically. For dynamic routes using ISR (Incremental Static Regeneration), the CDN serves a stale page while revalidating in the background:

Cache-Control: s-maxage=60, stale-while-revalidate=300

The s-maxage directive tells shared caches (CDN edges) how long to serve without checking origin. stale-while-revalidate lets the CDN serve an expired version while fetching a fresh one asynchronously. This is defined in RFC 5861.

Modern CDNs also support edge compute (Cloudflare Workers, Fastly Compute, Vercel Edge Functions), blurring the line between caching layer and application runtime.

When to use it

The short answer: almost always. Here's the honest breakdown.

Use a CDN when:

You serve static assets (images, fonts, JS bundles)—this is table stakes in 2026
Your audience is geographically distributed across regions or continents
You need to hit LCP under 2.5s for users far from your origin
You're running a Next.js or Astro site and want ISR/static pages served at the edge
You want DDoS mitigation as a side benefit (Cloudflare, AWS Shield)

Skip or be careful when:

Highly personalized, real-time content where every response is unique—CDN cache hit rates will be near zero, and you're just adding a hop
You have a single-region user base sitting next to your origin server—the latency savings won't justify complexity
Your cache invalidation strategy is unclear—serving stale data to millions of users is worse than being slow

We've shipped CDN configurations on 50+ projects. The biggest mistake we see: teams set long max-age values without a cache-busting strategy, then panic when a deploy doesn't show up.

CDN vs alternatives

Approach	Latency	Dynamic content	Complexity	Cost
CDN (Cloudflare, Fastly)	Low (edge-cached)	Supported via ISR/SWR	Medium	Free tier to $$$
Single origin server	High for distant users	Full control	Low	$
Edge runtime (Workers, Deno Deploy)	Low (compute at edge)	Full dynamic support	Higher	$$
Multi-region origin (fly.io)	Low	Full dynamic support	High	$$$

A CDN and an edge runtime aren't mutually exclusive—most edge runtimes sit behind a CDN cache layer anyway. The real question is whether you need edge caching (CDN) or edge compute (runtime). For a marketing site or blog, CDN caching alone gets you 95% of the performance benefit. For a logged-in dashboard with personalized data, you need edge compute or a multi-region origin.

Real-world example

We migrated an Astro-based documentation site from a single DigitalOcean droplet in NYC to Cloudflare Pages (which includes Cloudflare's CDN). Before the migration, users in Singapore saw TTFB of ~800ms. After, TTFB dropped to ~40ms for cached pages—a 95% reduction. LCP went from 3.8s to 1.4s, moving the site from "needs improvement" to "good" in Google's CrUX data within 28 days. The total cost change: from $12/mo on the droplet to $0/mo on Cloudflare's free tier. Cache hit ratio stabilized at 94% within the first week. The only gotcha was purging docs pages on git push—we wired a GitHub Action to call Cloudflare's purge API on deploy.

Frequently asked questions about CDN (Content Delivery Network)

Is a CDN the same as edge caching?

Not exactly. Edge caching is a core function of a CDN, but a CDN is a broader system. A CDN includes DNS-based routing, load balancing, DDoS protection, TLS termination, and often edge compute capabilities. Edge caching specifically refers to storing copies of content at geographically distributed nodes so repeat requests are served locally. You can implement edge caching without a traditional CDN (e.g., using Varnish at multiple self-managed PoPs), but in practice, almost everyone uses a CDN provider for this because the infrastructure investment is massive.

When did CDNs become standard for web development?

Akamai launched the first commercial CDN in 1998, but CDNs became standard practice for most web projects around 2015–2017. This shift was driven by three things: free CDN tiers (Cloudflare launched its free plan in 2010), the rise of static site generators that produce CDN-friendly output, and Google's increasing emphasis on page speed as a ranking signal (Speed Update in 2018, Core Web Vitals in 2021). By 2020, deploying without a CDN was considered a performance anti-pattern for any public-facing site. Today in 2026, platforms like Vercel, Netlify, and Cloudflare Pages include CDN distribution by default—you'd have to actively opt out.

What's the alternative to using a CDN?

The main alternatives are: (1) a single-origin server close to your primary audience, which works fine if your users are concentrated in one region; (2) a multi-region deployment using something like fly.io or AWS multi-region, where you run full application instances in multiple locations—this handles dynamic content better than a CDN cache but is more complex and expensive; (3) peer-to-peer delivery for specific use cases like video streaming (e.g., WebRTC-based approaches). For most web projects, the real alternative isn't avoiding a CDN, it's choosing between a CDN with edge caching only vs. a CDN with edge compute. Our preferred stack uses Vercel or Cloudflare, both of which bundle both.

Does a CDN help with SEO?

Yes, directly. Google confirmed page speed as a ranking factor with the Speed Update (2018) and formalized it through Core Web Vitals (2021). A CDN primarily improves TTFB, which cascades into better LCP scores—one of the three Core Web Vitals. Google's CrUX dataset measures real-user performance, so if your international users experience slow loads from a distant origin, it drags down your field data. We've seen sites move from 'needs improvement' to 'good' LCP status in CrUX simply by adding a CDN, with no other code changes. The SEO benefit isn't hypothetical—we've measured ranking improvements within 28–60 days of CrUX data improving on multiple client projects.

What is CDN (Content Delivery Network)?