The Edge Network: every deployment is global, by default

Cloud Computing's own CDN lesson described a CDN conceptually: static assets cached at edge locations close to users, reducing both latency and origin load. Vercel's Edge Network applies this automatically to every deployment's static assets and, critically, to Edge Functions themselves (lesson 5) — there's no separate CDN to configure, no cache-control headers to hand-tune before any benefit appears, and no decision about which regions to deploy to for a typical app; the distribution happens as a property of deploying at all.

Static assets (JS bundles, CSS, images, anything genuinely static) are cached aggressively and globally — identical for every user, safe to serve from anywhere. Statically-generated pages and ISR-rendered pages (lesson 4 covers ISR specifically) are also cached at the edge, which is exactly what makes them fast — but this means the same cache-correctness concerns Caching Strategies' own domain covered apply here too: a cached page is only correct to serve from an edge location until something invalidates it, and understanding when that invalidation happens (a new deployment, an ISR revalidation window expiring, an explicit on-demand revalidation call) is the difference between "the edge makes everything fast" and "why is this page showing stale content."

A team running its own server behind a CDN (the Cloud Computing domain's own architecture) has to explicitly configure cache rules, set Cache-Control headers correctly themselves, and manage CDN invalidation as a deliberate operational step. Vercel's platform handles the equivalent of all of this automatically for content it understands the shape of (a Next.js page, a static asset) — the trade-off is less manual control in exchange for not needing to configure or operate a CDN layer at all for the common case.

Static content being globally cached is a different thing from where a Serverless or Edge Function (lesson 5) actually executes — a Serverless Function runs in one specific region (configurable, defaulting to one close to where your team/database lives), while an Edge Function runs in whichever edge location is closest to the requesting user, globally, for every request. Confusing "my content is served from everywhere" with "my function's compute also runs everywhere" is a real, common misunderstanding this distinction exists specifically to prevent.