Hit
Answer from the nearest edge
When the edge already has a fresh object for this URL and deployment, visitors get the response locally. Compute does not run.
Every deploy ships with a global CDN.
Preview and production hosts get managed TLS, framework-aware caching, and tag revalidation automatically. No separate CDN product. Compute stays in named regions when the cache cannot answer.
41 edge locations
Traffic routes to the nearest edge for TLS, caching, and protection
Cached at the edge
Eligible GET and HEAD responses answer without running compute
On every deployment
Preview and production hosts use the same edge path automatically
A network where your users already are
41 edge locations handle TLS, routing, caching, and protection. Dynamic work continues in named compute regions when the cache cannot answer.
41
regions- Nearest-edge routing for every request
- Cached responses answered without compute
- Compute regions called out separately
North America
AshburnAtlantaBostonChicagoDallasDenverLos AngelesMiamiNew York CitySan JoseSeattleToronto
Europe
AmsterdamAthensBucharestCopenhagenFrankfurtLondonMadridMilanParisPragueStockholmViennaWarsawZagreb
Asia
BangkokHong KongIstanbulJakartaKuala LumpurManilaSingaporeTel AvivTokyo
South America
BogotaMexico CitySao Paulo
Oceania
Sydney
Africa
JohannesburgLagos
How a request gets answered
The edge decides first. Cache hits stay local. Misses reach compute and can refill the cache for the next request.
Miss
Continue to compute, then store
When the edge has nothing usable, the request continues to a named compute region. Eligible responses populate the edge for the next visitor.
Cache the responses that should be fast
CDN cache is for complete HTTP responses that many visitors can share: pages, assets, and public API payloads with a known lifetime.
Marketing and docs sites
Prerendered pages and static assets stay at the edge so every visitor gets a nearby copy.
Catalogs and storefronts
Cache product and listing responses, then expire them by tag when inventory or pricing changes.
Cacheable APIs
Public JSON that changes on a known schedule uses CDN lifetime headers without a separate CDN config ritual.
Frameworks that emit standard Cache-Control and CDN-Cache-Control headers get this behavior without a separate CDN product. For Next.js specifics, see Next.js on Easel.
Keep content fresh without waiting for TTL
When a product, post, or listing changes, expire the tagged edge objects so the next visitor gets a new response. One call can update CDN objects, Runtime Cache entries, and ISR pages that share the tag.
app/actions.ts
"use server";
import { revalidateTag } from "next/cache";
export async function publishProduct(id: string) {
await saveProduct(id);
revalidateTag(`product-${id}`);
revalidateTag("products");
}Ready to see this on a preview URL?
Book a call and ship a branch. The CDN is already on.
See whether the edge answered
HIT, MISS, STALE, BYPASS, and REVALIDATED are readable on the response. Caching follows documented headers and framework APIs, not a black box.
HIT
Cache HIT
The edge already had a fresh object for this URL and deployment.
- Compute
- Compute did not run
- What happens next
- Keep serving until TTL ends or a matching tag is expired.
Response headers
cache-control: public, s-maxage=300, stale-while-revalidate=60 age: 42 x-cache: HIT x-vercel-cache: HIT cache-tag: product:123, collection:featured
On by default for every host
You do not buy or enable a separate CDN. Domains, certificates, and compression ride the same edge path as platform hosts.
No CDN toggle
Every preview URL, production host, and custom domain is fronted by Easel CDN automatically.
Managed TLS
Certificates issue and renew at the edge for platform hosts and verified custom domains.
Smaller payloads
Eligible HTML, CSS, JS, and other text responses compress with Brotli or gzip based on Accept-Encoding.
Ship a preview. The CDN is already in front of it.
Book a call, deploy a branch, and serve from the edge on the first preview URL.