What is Edge Cache?

Edge cache is a content caching layer deployed at geographically distributed CDN edge nodes — the servers physically closest to your users. Instead of every request traveling back to your origin server (which might sit in us-east-1), edge-cached responses are served from the nearest point of presence (PoP). This typically reduces Time to First Byte (TTFB) from 200-800ms down to 10-50ms for cached assets. Edge caching applies to static assets (images, CSS, JS bundles), but increasingly to dynamic HTML and API responses too, especially with platforms like Vercel, Cloudflare, and Fastly. The Cache-Control and CDN-Cache-Control headers (the latter formalized around 2023 by major CDNs) give you fine-grained control over what gets cached at the edge versus the browser. We use edge caching on virtually every Next.js project we ship to keep TTFB under the 800ms "good" threshold defined by Google's Core Web Vitals.

How it works

When a user requests a page, the request hits the nearest CDN edge node first. The edge node checks its local cache:

Cache HIT — The edge node has a fresh copy. Returns the response immediately. No origin roundtrip.
Cache MISS — No cached copy exists (or it's stale). Edge node forwards the request to origin, caches the response according to its headers, then returns it.
STALE-WHILE-REVALIDATE — Edge serves a stale copy instantly while fetching a fresh version from origin in the background.

Here's a typical Cache-Control header for an edge-cached Next.js page:

Cache-Control: public, s-maxage=3600, stale-while-revalidate=59

public — Any shared cache (edge node) can store this.
s-maxage=3600 — Edge cache treats this as fresh for 1 hour.
stale-while-revalidate=59 — After 1 hour, serve stale for up to 59 seconds while revalidating in the background.

In Next.js App Router (v14+), you can set these headers in next.config.js via the headers() function or directly in route handlers. Vercel's Edge Network respects s-maxage natively. Cloudflare uses CDN-Cache-Control as an override layer, letting you set edge TTLs independently from browser TTLs.

The critical nuance: max-age controls browser cache, s-maxage controls shared (edge) cache. Mixing these up is one of the most common caching bugs I debug.

When to use it

Edge caching is default-on for us. But not everything belongs there.

Use edge cache when:

Serving marketing pages, blog posts, docs, or any content that changes infrequently
You need low TTFB globally (e-commerce product pages, landing pages)
API responses are identical for all users (public catalog data, pricing)
You're using ISR (Incremental Static Regeneration) in Next.js — ISR is literally edge caching with built-in revalidation

Skip edge cache (or be very careful) when:

Responses are user-specific (authenticated dashboards, cart data) — caching these at the edge can leak private data to other users
Content changes every few seconds and stale data causes real harm (live bidding, stock tickers)
You're debugging cache-related issues — add Cache-Control: no-store temporarily and work backward

The biggest footgun? Accidentally caching a response that contains a Set-Cookie header. Most CDNs won't cache these by default, but custom configurations can override that protection.

Edge Cache vs alternatives

Strategy	Where it lives	Latency	Freshness control	Best for
Edge Cache	CDN PoPs (100+ locations)	10-50ms	`s-maxage`, `stale-while-revalidate`	Public pages, static assets
Browser Cache	User's device	0ms (from disk/memory)	`max-age`, `ETag`, `Last-Modified`	Repeat visits, immutable assets
Origin Cache	Your server (Redis, Varnish)	50-200ms + network	Application-level TTLs	Expensive DB queries, computed data
Edge Runtime	CDN PoPs (compute, not just cache)	10-50ms (but executes code)	On-demand	Personalization at the edge, A/B tests

Edge cache and edge runtime are complementary, not interchangeable. Edge cache stores responses. Edge runtime runs code. On Vercel, a Next.js middleware runs on the edge runtime and can decide whether to serve from edge cache or compute a fresh response.

Real-world example

We shipped a Next.js 14 marketing site for a SaaS client with ~2,000 pages. Without edge caching, origin TTFB averaged 380ms for US users and 900ms+ for users in Southeast Asia. After configuring ISR with revalidate: 3600 (which sets s-maxage=3600 on Vercel's Edge Network), TTFB dropped to 18-35ms globally on cache hits. Cache hit rates stabilized around 94% within the first week. Origin server load dropped by roughly 85%, which let us downsize from a 4-vCPU instance to a 1-vCPU instance. For cache invalidation on CMS publishes, we used Vercel's on-demand revalidation API (revalidatePath()) triggered by a Sanity webhook — fresh content propagated to edge nodes within 1-2 seconds.

Frequently asked questions about Edge Cache

Is edge cache the same as a CDN?

Not exactly. A CDN is the network of distributed servers (edge nodes). Edge cache is the caching behavior that happens on those servers. You can use a CDN without caching (e.g., as a reverse proxy or DDoS shield), and you can configure CDN nodes to bypass cache entirely with `Cache-Control: no-store`. That said, in everyday conversation, when people say "put it on the CDN" they usually mean "edge cache it." The CDN is the infrastructure; the edge cache is a function of that infrastructure.

When did edge caching become standard for web apps?

Edge caching for static assets (images, CSS, JS) has been standard since the early CDN era — Akamai launched in 1998. But edge caching for dynamic HTML and API responses became mainstream around 2019-2021, driven by Vercel's adoption of ISR in Next.js 9.5 (July 2020) and Cloudflare Workers' Cache API. By 2023, every major hosting platform (Vercel, Netlify, Cloudflare Pages, AWS CloudFront) supported some form of dynamic edge caching with programmatic invalidation. It's now a baseline expectation for production web apps.

What's the alternative to edge caching?

The main alternatives are origin-level caching (Redis, Varnish, Nginx `proxy_cache`) and browser caching. Origin caching still requires every request to reach your server, so it doesn't solve global latency. Browser caching eliminates network requests entirely on repeat visits, but doesn't help first-time visitors. For server-rendered pages, you can also use full static generation (SSG) and deploy the HTML files directly to a CDN — this is effectively edge caching without a dynamic origin at all. We often combine all three: SSG or ISR for edge, Redis for origin fallback, and aggressive `max-age` for immutable assets in the browser.

How do you invalidate an edge cache?

Three common approaches: (1) **TTL-based expiry** — set `s-maxage` and let the cache expire naturally. Simple but you wait for the TTL. (2) **On-demand purge/revalidation** — call an API to invalidate specific paths or cache tags. Next.js offers `revalidatePath()` and `revalidateTag()` since v13.4. Cloudflare supports purge-by-URL and purge-by-tag via their API. (3) **Surrogate keys / cache tags** — tag cached responses with identifiers (e.g., `product-123`) and purge all responses matching a tag at once. Fastly pioneered this with `Surrogate-Key` headers. We prefer on-demand revalidation triggered by CMS webhooks — it's the best balance of freshness and cache hit rate.