Edge Caching
Storing pre-generated responses on CDN edge servers so subsequent requests are served without contacting the origin server. Critical for low TTFB.
§ 1 Definition
Edge caching is the practice of storing HTTP responses (HTML pages, API responses, static assets) on CDN edge servers (PoPs) so they can be served directly to users without forwarding the request to the origin server. Cache hit responses arrive in 10-50 ms vs origin responses that take 200-1000+ ms. Effective edge caching requires proper cache-control headers, cache key design, and invalidation strategies.
§ 2 Cache Control Strategies
Use Cache-Control headers to tell CDNs how to cache: public vs private, max-age (how long), stale-while-revalidate (serve stale while fetching fresh), and s-maxage (override for shared caches). For cache keys: include the host, URL path, and query parameters. Exclude cookies, user-agent, and other irrelevant headers unless they affect content.
§ 3 Common Misunderstandings
Long max-age values are NOT dangerous if paired with stale-while-revalidate. A max-age of 31536000 (1 year) with stale-while-revalidate=86400 means the CDN serves instantly from cache and refreshes in the background. Also, purging the cache does not make content immediately available: the response must be fetched from origin before it is cached at the edge.
§ 4 Cache Invalidation
Use purge APIs to remove cached content when it changes. Tag-based purging (using Cache-Tag headers) allows invalidating groups of URLs. Surrogate-Key headers achieve similar functionality. For static assets, use content-hash-based filenames to avoid needing invalidation at all: a new hash creates a new cache entry.
§ 5 Note
§ 6 In code
# Cache-Control: max-age=31536000, stale-while-revalidate=86400
# Cache-Tag: product-page, home-page, v2
# Asset with content hash
<link rel="stylesheet" href="/styles.a1b2c3.css">§ 7 Common questions
- Q. What is the difference between edge caching and browser caching?
- A. Edge caching caches on the CDN (shared between all users). Browser caching caches on the user's device (local).
- Caches responses on CDN edge servers.
- Critical for low TTFB.
- Use Cache-Control, Cache-Tag headers.
- Use content hashes to avoid invalidation.
Atomic Glue configures edge caching rules, cache headers, and invalidation strategies to maximize cache hit ratios and minimize origin load. Web Development services.
Get in touchStoring pre-generated responses on CDN edge servers so subsequent requests are served without contacting the origin server. Critical for low TTFB.
Category: Performance (also: Infrastructure)
Author: Atomic Glue Performance Team
## Definition
Edge caching is the practice of storing HTTP responses (HTML pages, API responses, static assets) on CDN edge servers (PoPs) so they can be served directly to users without forwarding the request to the origin server. Cache hit responses arrive in 10-50 ms vs origin responses that take 200-1000+ ms. Effective edge caching requires proper cache-control headers, cache key design, and invalidation strategies.
## Cache Control Strategies
Use Cache-Control headers to tell CDNs how to cache: public vs private, max-age (how long), stale-while-revalidate (serve stale while fetching fresh), and s-maxage (override for shared caches). For cache keys: include the host, URL path, and query parameters. Exclude cookies, user-agent, and other irrelevant headers unless they affect content.
## Common Misunderstandings
Long max-age values are NOT dangerous if paired with stale-while-revalidate. A max-age of 31536000 (1 year) with stale-while-revalidate=86400 means the CDN serves instantly from cache and refreshes in the background. Also, purging the cache does not make content immediately available: the response must be fetched from origin before it is cached at the edge.
## Cache Invalidation
Use purge APIs to remove cached content when it changes. Tag-based purging (using Cache-Tag headers) allows invalidating groups of URLs. Surrogate-Key headers achieve similar functionality. For static assets, use content-hash-based filenames to avoid needing invalidation at all: a new hash creates a new cache entry.
## Note
Edge caching is only effective for cacheable content. Personalized or user-specific responses should be marked private or bypass the CDN.
## In code
# Cache-Control: max-age=31536000, stale-while-revalidate=86400 # Cache-Tag: product-page, home-page, v2 # Asset with content hash <link rel="stylesheet" href="/styles.a1b2c3.css">
## Common questions
Q: What is the difference between edge caching and browser caching?
A: Edge caching caches on the CDN (shared between all users). Browser caching caches on the user's device (local).
## Key takeaways
- Caches responses on CDN edge servers.
- Critical for low TTFB.
- Use Cache-Control, Cache-Tag headers.
- Use content hashes to avoid invalidation.
## Related entries
- [Browser Caching](atomicglue.co/glossary/browser-caching)
- [Content Delivery Network (CDN)](atomicglue.co/glossary/content-delivery-network-cdn)
- [TTFB (Time to First Byte)](atomicglue.co/glossary/ttfb-time-to-first-byte)
Last updated July 2026. Permalink: atomicglue.co/glossary/edge-caching