10 min read
A content delivery network (CDN) caches your web content on servers around the world so every response comes from somewhere close to the person requesting it. Modern CDNs do more than cache static files: they terminate TLS at the edge, run compute before requests reach your origin, and handle routing and traffic management across a global network.
This guide covers how CDNs work under the hood, what kinds of content they can deliver, and how to pick the right provider for your setup.
Link to headingWhat is a CDN?
A CDN is a geographically distributed group of servers that sit between your origin and the browser. Think of it as a middle layer: instead of every request traveling all the way back to your origin, it gets handled by a nearby node that already has a cached copy of your content.
Say a request from Tokyo needs to reach an origin server in Virginia. Without a CDN, it pays the full round-trip cost of that distance. With a CDN in place, the request hits a nearby node first. If the node has a cached copy, it responds immediately and your origin never sees the request. If it doesn't, the node fetches the content from a regional cache tier or the origin, stores a copy locally, and serves it directly on the next request.
Link to headingWhy teams use CDNs
A CDN makes your site faster, cuts bandwidth costs, adds redundancy, and filters bad traffic. When your cache policy and routing are set up well, a single CDN handles all of these at once.
Link to headingFaster page load times
Visitors don't wait around for slow pages. CDNs shorten the distance between your server and the browser, which lowers Time to First Byte (TTFB) for cacheable responses. A lower TTFB means the browser starts receiving content sooner, and that directly affects metrics like Largest Contentful Paint as outlined in Google's LCP guidance. You'll see the biggest gains when your HTML, CSS, fonts, images, and JavaScript bundles all load from a nearby node.
That speed difference shows up in real business outcomes: lower bounce rates, longer sessions, and customers who make it through checkout instead of dropping off. A CDN won't fix every performance issue, but it takes a clear chunk out of the network portion of your page-load path. Vercel's caching documentation covers this in more detail, and for multi-region apps, a before-and-after test is the most direct way to measure the impact.
Link to headingLower bandwidth costs
Every response served from cache is one fewer response your origin has to generate, which means less compute and less egress (outbound data transfer). Image-heavy sites, ecommerce sites, documentation portals, and media libraries save the most because those same responses repeat across every region.
Compression and protocol optimization help too. When your Cache-Control headers have the right TTLs and your asset versioning is consistent, you can push a big share of traffic into the cache layer and keep it off the origin.
Link to headingGreater availability and redundancy
A CDN spreads delivery across multiple regions, so you're not relying on a single server to handle every page load, asset request, and API call. If one region slows down, traffic management routes requests to healthier nodes while keeping cached content nearby.
Because delivery is spread across regions, your origin handles less work per request. The cache layer handles repetitive file serving, so the origin can focus on dynamic rendering, API calls, and database queries.
Link to headingStronger security and traffic filtering
CDNs inspect and filter traffic at the edge before it ever reaches your app: rate limiting, bot detection, TLS termination, Web Application Firewall (WAF) rules, and traffic shaping across distributed Points of Presence (PoPs).
Because this filtering happens closer to the source, your origin servers have more headroom during traffic spikes, product launches, and bot attacks. The same network that speeds up delivery also sits between public traffic and your infrastructure, filtering out what shouldn't get through.
Link to headingHow a CDN works under the hood
A CDN has three main moving parts: edge caches store your content close to the browser, routing logic picks the fastest path for each request, and connection optimization speeds up even the requests that can't be cached.
Link to headingCaching content at edge servers
CDN nodes sit at major network interconnection points and store cached copies of your content. When a request comes in, the node checks its local cache using a key built from the URL path, query parameters, and relevant headers. A hit returns the response directly. A miss triggers a fetch from a regional tier or the origin.
You control cache behavior through Cache-Control headers. s-maxage sets the TTL (time to live) for shared caches like CDN nodes, and stale-while-revalidate serves stale content immediately while revalidating in the background. The CDN cache behavior documentation covers these headers in depth. If your cache hit rates drop, auditing cache keys and TTLs is the best place to start.
Link to headingAccelerating dynamic requests
Even content that can't be cached gets faster through a CDN. CDNs terminate TCP and TLS connections at the nearest node, then forward requests to the origin over persistent connections on a shorter path.
The TLS handshake still has the same number of round-trips, but each one travels a much shorter distance. The CDN's upstream connections to your origin are already established, so they skip the setup cost that normally adds latency to every cache miss.
Link to headingRouting traffic across nodes
Most CDNs route traffic based on proximity and health checks, rather than sending every request to a single origin. This keeps requests landing on fast, healthy nodes.
CDNs can also collapse simultaneous requests for the same uncached resource into a single origin fetch. So if one popular asset expires, you don't get a stampede of duplicate requests hitting your origin at the same time.
Link to headingTypes of content a CDN can serve
CDNs handle three broad categories of content, and each one needs a different caching strategy depending on whether the response is immutable, changes on a schedule, or is personalized per request.
Link to headingStatic content
Static assets like images, CSS, JavaScript bundles, and fonts are where CDNs shine. Content-fingerprinted files like app.a1b2c3d4.js can use Cache-Control: public, max-age=31536000, immutable, which tells the CDN to cache them for a full year. Any code change produces a new filename, so stale versions get bypassed automatically.
For global audiences, this means consistent, fast delivery for every asset in every region. It also makes invalidation simple because the filename itself is the version boundary, not a cache purge.
Link to headingDynamic content
Personalized pages, API responses, and server-rendered output can't be fully cached because they change based on session, auth state, location, or live data. But shared components like headers and footers, short-lived HTML, and stale-while-revalidate patterns still cut latency for responses that have even a small reuse window.
Some CDN platforms take this further by integrating caching with framework-level features. Next.js, for example, supports Incremental Static Regeneration (ISR), which refreshes cached pages in the background while the previous version stays live. You get fresh content and fast delivery without having to pick one or the other.
Link to headingStreaming content
Streaming protocols like HLS (HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP) split video into segments at multiple quality levels, all delivered over standard HTTP. CDNs cache these segments aggressively while keeping manifest files on short TTLs, since manifests change more often during live streams.
Low-latency variants cut delay through partial segment delivery, and WebRTC (Web Real-Time Communication) keeps persistent connections open for interactive use cases like video calls. In both cases, the CDN's connection capacity and geographic reach matter even when the cache hit ratio isn't the main number you're watching.
Link to headingCommon CDN use cases
Most production web apps use a CDN in some form, but the value looks different depending on what you're building. An e-commerce team prioritizes checkout speed during a product launch, a SaaS team needs multi-tenant caching, and a media company focuses on delivering video across 30 countries without buffering:
E-commerce: Better Core Web Vitals and launch-day traffic handling contribute to higher conversions and stronger uptime SLAs. CDNs also filter bad requests before they ever reach your checkout services.
SaaS platforms: Multi-tenant content distribution and API caching are the starting point, but the bigger win is often tenant-aware security rules that would otherwise need custom middleware at the origin.
Media and streaming: Regional delivery across dozens of countries is a given. Avoiding outages usually means running multi-provider CDN setups instead of depending on one network.
API-heavy architectures: Pushing rate limiting, token checks, and request filtering closer to the edge keeps your backend focused on application logic and draws a cleaner line between public traffic and internal systems.
For most teams today, a CDN is part of how you ship.
Link to headingChoosing a CDN provider
How CDN providers compare depends on where your traffic comes from, what you're caching, and how your origin works. The bigger differences come down to security features, how it fits your tech stack, and whether it plugs into your deployment process without extra manual work.
Link to headingMeasure real-user performance, not synthetic averages
Look at 90th-percentile latency from the regions where your app actually has traffic, not averages from synthetic tests. The Chrome UX Report shows how real people experience your site across different networks and devices, which is a more relevant baseline than lab tests alone. Running two or three providers side by side for a few weeks gives you a clear picture of cache hit rates, origin shielding (how well the CDN absorbs traffic before it reaches your server), and consistency across regions.
Also, look at the PoP map. A provider might cache static assets from hundreds of locations but only run compute in a handful, and that gap changes latency for anything that needs dynamic rendering or request-time logic.
Link to headingTest security against your actual traffic patterns
Compare how each provider handles your real traffic, not just the capacity numbers on a spec sheet. Check DDoS mitigation, WAF controls, bot management, TLS defaults, and logging against your own compliance needs.
The real test is whether the provider's security rules work with your routes, cookies, APIs, and auth flows without constant tuning.
Link to headingCheck whether it fits your deployment pipeline
Pick a CDN that fits how you already ship code, not one that makes you redesign your workflow. Check Terraform support, CLI tooling, cache invalidation APIs, and framework compatibility, because these determine how much work the CDN adds to each release.
Plan your migration path before you switch, too. Configuration export, clear rollback paths, and good documentation make it easier to commit to a provider long-term.
Link to headingHow Vercel's global network powers CDN delivery
Most CDNs require you to configure caching rules separately from your application code. Vercel's global network takes a different approach. Your cache behavior comes directly from your app's output, so there's no separate CDN layer to manage. If you're using Next.js, features like ISR, route-level rendering, and cache revalidation work automatically based on your app's config. SvelteKit, Nuxt, TanStack Start, and Astro plug into the same caching and routing, though the level of automatic behavior varies by framework.
On top of that, Partial Prerendering lets you serve a static shell instantly while streaming dynamic content afterward, and Routing Middleware handles request-level logic such as A/B testing, geolocation routing, and header rewrites during the routing phase. Every deployment ships with built-in traffic protection and a git-based workflow, so your CDN config travels with your code instead of living in a separate dashboard.
Link to headingCDN-first architecture and what comes next
The best CDN setups treat caching, routing, and request handling as part of the application itself, not as a separate layer you manage on the side. When your framework, deployment flow, and cache strategy all work together, the CDN becomes invisible: it does its job on every deploy without you thinking about it.
If you're figuring out where to start, run a short measurement cycle with your own traffic before committing to a full migration. Once you're ready to test it, start with a template to see how framework-aware CDN caching, ISR, and Partial Prerendering work on Vercel's global network.
Link to headingFrequently asked questions about CDNs
Link to headingDo I need a CDN for a small website?
It can still help, especially if your site gets visitors from different regions or relies on static assets. A CDN also moves TLS termination and basic traffic filtering closer to the request path, which is useful even at a smaller scale.
Link to headingDoes a CDN help with SEO?
Indirectly, yes. Faster delivery of HTML and static assets can improve page speed, which is part of the user experience signals Google considers in Core Web Vitals. But the impact depends on the rest of your page architecture, not just the CDN.
Link to headingWhat is the difference between a CDN and web hosting?
Web hosting stores your actual content, databases, and application logic at a central origin. A CDN distributes cached copies of that content across nodes worldwide. Your origin handles data access and app logic, while the CDN handles cached delivery, TLS termination, and geographic routing.
Link to headingCan a CDN protect against DDoS attacks?
Yes. A CDN spreads incoming traffic across distributed locations, applies rate limits close to the source, and filters requests before they hit your origin. That keeps legitimate traffic flowing and gives your servers more breathing room during large spikes.