Edge computing
Edge computing means running your code at a CDN's points of presence instead of (or in front of) a central origin server. Cloudflare Workers, Fastly Compute and CloudFront Functions/Lambda@Edge all follow the same idea: the request is handled milliseconds from the user, before it ever crosses an ocean to your infrastructure.
What runs well at the edge
- Request rewriting — redirects, A/B bucketing, header manipulation, geo-based routing, auth checks.
- Cache programmability — normalizing cache keys, caching responses the CDN's default rules would skip, or serving different cached variants per segment. On Cloudflare this is the Workers Cache API.
- Assembling responses — stitching cached fragments with small dynamic parts (personalized header, cart count) so the bulk of the page stays cacheable instead of going fully dynamic.
- Full applications — increasingly, whole apps run at the edge with edge-hosted data (KV stores, D1, Durable Objects), collapsing the origin entirely.
Why it matters for caching
Edge compute and edge caching solve the same problem from two sides. Caching makes repeated responses fast; edge code makes the uncacheable parts fast — and, used well, it converts "dynamic" pages back into cacheable ones. The classic failure mode it fixes: one personalized element (a cookie, a currency switcher) forcing an entire page to bypass the cache. Move that element into edge code and the page returns to being a cache hit for everyone.
The caveat: edge caches still start cold
Edge functions run everywhere instantly, but any cache they populate is still per-PoP: what a Worker caches in Frankfurt does nothing for Sydney. The economics of eviction and cold starts apply unchanged — which is why edge-heavy architectures still benefit from cache warming across regions. See how your edge responds per location with the website speed test.