Esc
↑↓ navigate   Enter open   Esc close

Infrastructure comparison

CDN vs Edge Computing

Both CDNs and edge computing move work closer to users by placing infrastructure at hundreds of points of presence (PoPs) around the globe. But they do fundamentally different things: a CDN caches and serves content, while edge computing executes code. Understanding the distinction is essential for architecture discussions, cloud cost reviews, and performance optimisation conversations at work.

TL;DR

  • CDN (Content Delivery Network) caches static assets — HTML, CSS, JavaScript bundles, images, video — at PoPs near users. Requests are served from cache without touching the origin server. Ideal for content that does not change per user.
  • Edge computing runs code at PoPs. Instead of simply serving files, edge functions (Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge) execute logic. Ideal for personalisation, authentication, A/B testing, and dynamic API responses.
  • Both reduce latency by moving work geographically closer to users. The difference is what they move: data (CDN) versus computation (edge).

Side-by-side comparison

AspectCDNEdge Computing
Primary purposeCache and serve static assetsExecute code close to the user
Content typeStatic: HTML, CSS, JS bundles, images, videoDynamic: per-user responses, auth checks, redirects, API transforms
ComputeNone — pure caching and routingFull JavaScript / Wasm execution environment
Latency benefitEliminates round trip to origin for cached assetsRuns logic at the nearest PoP instead of a single central region
StateCache state governed by TTL and cache invalidation rulesMostly stateless; some platforms provide edge KV stores
Cold/warm cacheWarm = instant from PoP; cold = fetched from origin on first hitCold start = first isolate spin-up; warm isolate reuses existing V8 context
ExamplesCloudflare CDN, AWS CloudFront (caching mode), Fastly, AkamaiCloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge, Deno Deploy
Pricing modelPer GB transferred + cache hit ratioPer request + CPU time consumed
Best forServing large files, reducing bandwidth cost, DDoS mitigationPersonalisation, geo-routing, edge auth, real-time API responses

What is a CDN?

A Content Delivery Network is a geographically distributed network of servers — each one called a point of presence (PoP) — that caches copies of your content close to users. When a user in Melbourne requests your website, instead of the request travelling to your origin server in Frankfurt, the nearest PoP in Sydney serves the response from its local cache.

CDNs are built around the idea that most content is static: it does not change between users or between requests within a given time window. A CSS file, a JavaScript bundle, a product image — these can be cached aggressively. The CDN stores the response after the first cache miss (a request that travels all the way to the origin), then serves all subsequent requests as cache hits directly from the PoP.

The period a cached response is considered valid is controlled by its TTL (Time to Live), typically set via Cache-Control headers. When you deploy new code, you need to invalidate the cache — explicitly marking entries stale — or use content hashing in filenames (e.g. main.a3f9c1.js) so that each deploy produces a new URL and the old one expires naturally.

What is edge computing?

Edge computing takes the geographical distribution of a CDN and adds a runtime: instead of just caching files, the edge nodes can execute code. Each PoP runs your function within milliseconds of the user, without a round trip to a central server.

The leading platforms — Cloudflare Workers, Vercel Edge Functions, and AWS Lambda@Edge — use V8 isolates rather than containers. An isolate is a lightweight, sandboxed JavaScript execution context. Because there is no OS process to boot, cold starts are measured in microseconds rather than the hundreds of milliseconds typical of container-based serverless functions.

The trade-off is a restricted Edge runtime: no file system access, no native Node.js modules, strict CPU and memory limits. Frameworks like Next.js let you opt individual route handlers into the Edge runtime, so a personalisation endpoint runs at the edge while a data-heavy admin route stays on a standard Node.js server.

Edge compute is particularly powerful for dynamic content that varies per user but does not require a database round trip on every request — for example, reading a country code from the request headers and returning a localised response from an in-memory lookup, or validating a JWT and rejecting unauthorised requests before they ever reach your origin.

Code side-by-side

Configuring a CDN cache policy versus writing an edge function that personalises responses:

CDN — CloudFront cache behaviour

{`# Cache static assets at the PoP
CacheBehaviors:
  - PathPattern: "/static/*"
    Compress: true
    DefaultTTL: 86400      # 1 day
    MaxTTL: 31536000       # 1 year
    ViewerProtocolPolicy: redirect-to-https
    CachedMethods: [GET, HEAD]

# Cache HIT  → served from PoP, no origin contact
# Cache MISS → fetched from origin, then cached
# Invalidation via: aws cloudfront
#   create-invalidation --paths "/static/*"`}

Edge compute — Cloudflare Worker

{`// Runs at the nearest PoP — no origin needed
export default {
  async fetch(request) {
    const country = request.cf?.country;

    // Geo-redirect at the edge
    if (country === 'DE') {
      const path = new URL(request.url).pathname;
      return Response.redirect(
        'https://example.de' + path, 302
      );
    }

    // Validate JWT before hitting origin
    const token = request.headers.get('Authorization');
    if (!isValidToken(token)) {
      return new Response('Unauthorised', { status: 401 });
    }

    return fetch(request); // pass through to origin
  }
};`}

How engineers talk about CDN vs edge computing

These phrases appear regularly in architecture reviews, incident post-mortems, and pull request discussions. Understanding them will help you follow and contribute to these conversations.

  • "We need to invalidate the cache after deployment — otherwise users will get stale assets." Said during a deployment checklist review. Stale assets are a frequent source of hard-to-reproduce bugs after a release.
  • "The cache hit rate is 94% — only 6% of requests are reaching the origin." A high cache hit rate means the CDN is working well. Below ~80% warrants investigation into cache headers or TTL configuration.
  • "We're doing auth at the edge to reject bad tokens before they hit the API." Describes moving authentication logic to a Cloudflare Worker or Lambda@Edge, reducing load on the origin and improving response times for rejected requests.
  • "The first request to that PoP is a cold cache miss — subsequent ones will be fast." Explains why a user in a new region sees slower performance initially. Common in discussions about pre-warming caches before a launch.
  • "Workers use V8 isolates, so the cold start is sub-millisecond — not the 200 ms you get with Lambda." Highlights a key advantage of isolate-based edge runtimes over container-based serverless functions for latency-sensitive code paths.
  • "We use content hashing for cache busting — no more manual invalidations on deploy." Describes the practice of embedding a file content hash in the filename so each new version gets a unique URL. Standard in modern front-end build pipelines.
  • "The edge function reads from KV, not the database — that's how it stays within the CPU time limit." Explains why edge KV stores (Cloudflare KV, Vercel Edge Config) are used instead of traditional databases, which cannot be reached efficiently from every PoP.
  • "This is static content — there's no reason for it to bypass the CDN." A common code review or architecture comment when a route is marked as dynamic but has no per-user variance, unnecessarily bypassing caching and increasing origin load.

Decision guide: CDN or edge compute?

Use this as a starting point — most production systems end up using both.

  • Serving images, fonts, JS bundles, CSS, video → CDN
  • Same response for all users, safely cacheable → CDN
  • Need to reduce origin bandwidth costs → CDN
  • DDoS mitigation, absorbing traffic spikes → CDN
  • Per-user personalisation (auth, geo, A/B experiments) → Edge compute
  • Need to run code before the request reaches your origin → Edge compute
  • URL rewrites, request header manipulation, response transformation → Edge compute
  • Large file delivery without per-user logic → CDN
  • API gateway logic (auth, rate limiting, routing) at global scale → Edge compute
  • Both? → yes — use CDN for assets, edge compute for dynamic logic; they run on the same PoP network

Key vocabulary

  • PoP (Point of Presence) — a datacenter location in the CDN or edge network's global footprint, physically close to a group of end users.
  • Origin server — the primary server that generates authoritative responses; CDNs and edge nodes sit in front of it as a reverse proxy layer.
  • Cache hit — a request served directly from the CDN's local cache at the PoP, without contacting the origin.
  • Cache miss — a request the CDN cannot serve from cache; it must be forwarded to the origin, which is then cached for subsequent requests.
  • Warm cache / cold cache — a warm cache has a valid stored copy; a cold cache (or cold PoP) has no stored copy and must fetch from origin on the first request.
  • TTL (Time to Live) — how long a cached response is considered valid before the CDN must re-fetch it from origin.
  • Cache invalidation — explicitly expiring cached entries before their TTL, typically triggered after deploying updated content.
  • Edge functions — code deployed to CDN edge nodes that executes per-request logic. Examples: Cloudflare Workers, Vercel Edge Functions, Lambda@Edge.
  • Edge runtime — a restricted JavaScript execution environment for edge nodes; no file system, no full Node.js API, but sub-millisecond cold starts.
  • V8 isolate — the sandboxed JavaScript context used by Cloudflare Workers; starts in microseconds rather than the seconds needed to boot a container.
  • Cold start — the latency of initialising a new execution context for the first request. Edge isolates: ~0 ms; containers: 100–500 ms.
  • Static vs dynamic content — static content is identical for all users and cacheable; dynamic content varies per user, session, or real-time state.
Is Cloudflare Workers a CDN or edge computing?

Cloudflare Workers is edge computing — it executes JavaScript (or WebAssembly) code at Cloudflare's points of presence around the world. Cloudflare also operates a CDN for caching static assets, so the two capabilities coexist on the same network. Workers can intercept and transform CDN responses, add authentication, perform A/B testing, or generate responses entirely without an origin server. The distinction is compute (Workers) vs caching (CDN), even though they run on the same physical infrastructure.

What is the difference between a warm cache and a cold cache?

A warm cache has a stored copy of a response ready to serve immediately — the CDN edge node has already fetched and cached the asset. A cold cache means no cached copy exists yet at that PoP; the first request must travel to the origin server, incurring the full round-trip latency. After that first request, the cache becomes warm. For globally distributed CDNs, a PoP in Sydney may be cold even if the one in London is warm, because each node has its own cache storage.

What is cache invalidation and why is it notoriously difficult?

Cache invalidation is the process of explicitly marking cached content as stale before its TTL expires — typically triggered after a deployment or content update. It is famously difficult because distributed CDN nodes may not all invalidate simultaneously, leaving some users served stale content. A common workaround is cache-busting via content hashing: include a hash of the file contents in the filename (e.g. main.a3f9c1.js), so each deployment produces a new URL that is automatically a cache miss, while old URLs expire naturally.

Related comparisons