Caching
Cache Configuration
Understand how Edge CDN caches your content and optimize cache behavior for maximum performance.
How Caching Works
When a request comes in, Edge CDN first checks if the content is in the cache:
Content is in cache and still valid. Served directly from the edge node in milliseconds.
Content is not in cache. Fetched from origin, cached, then served to the user.
Response Headers
Edge CDN adds headers to help you debug cache behavior:
HTTP/2 200
content-type: image/jpeg
x-cache: HIT
x-cache-hits: 47
x-edge-location: eu-west-1
cache-control: public, max-age=31536000
age: 3600x-cache Whether the request was a HIT (served from cache) or MISS (fetched from origin) x-cache-hits Number of times this item has been served from this edge node x-edge-location The edge node that served the request age How long the item has been in cache (in seconds) Cache TTL (Time to Live)
Cache TTL determines how long content stays in the cache before being refreshed from origin.
Edge CDN respects Cache-Control headers from your origin.
Set these headers on your origin server to control cache behavior.
You can also configure path-based caching rules in the Configuration tab to override TTLs or bypass caching for specific paths.
Recommended TTLs by content type
| Content Type | Recommended TTL | Cache-Control Header |
|---|---|---|
| Images (versioned) | 1 year | public, max-age=31536000, immutable |
| CSS/JS (versioned) | 1 year | public, max-age=31536000, immutable |
| Images (non-versioned) | 1 day | public, max-age=86400 |
| HTML pages | 5 minutes | public, max-age=300 |
| API responses | No cache | private, no-cache |
What Gets Cached
By default, Edge CDN caches responses that:
-
Return a 200 OK status code -
Have a cacheable Cache-Controlheader -
Are GET or HEAD requests
Content that is NOT cached
-
Responses with Cache-Control: no-storeorprivate -
POST, PUT, DELETE requests -
Responses with Set-Cookieheaders -
Error responses (4xx, 5xx)
Pause Cache (Proxy Mode)
During development or debugging, you may want to temporarily bypass caching and have all requests go directly to your origin. The Pause Cache feature puts your CDN deployment into proxy mode.
What happens when cache is paused:
- All requests skip cache lookup and go directly to origin
- Responses are NOT stored in cache
- Request metrics still record (as cache misses)
- Existing cached content remains in cache but is not served
How to pause cache
You can pause caching for a deployment from two places:
- Deployment header: Click the
Pause Cachebutton in the top-right corner of any deployment detail page. - Deployments table: Use the
Pausebutton in the Actions column on the main CDN dashboard.
Screenshot: Pause Cache button in deployment header
Use cases
See changes immediately without waiting for cache to expire or purging manually.
Verify origin responses directly without cache interference when troubleshooting issues.
Test origin changes or new deployments with live traffic before enabling caching.
Quickly bypass caching if you suspect cached content is causing issues.
Remember to resume caching when you're done debugging. Running in proxy mode means every
request hits your origin, which increases load and latency. Click Resume Cache
to restore normal caching behavior.
Cache Hit Rate
Monitor your cache hit rate in the analytics dashboard. A higher hit rate means more requests are being served from cache, reducing origin load and improving performance.
Screenshot: Analytics showing cache hit rate over time
Set-Cookie Response Handling
To protect user privacy and prevent session security issues, Edge CDN automatically
detects responses containing Set-Cookie
headers and excludes them from caching.
Why This Matters
If a response containing a Set-Cookie
header were cached and served to other users, those users would receive cookies intended
for someone else. This could cause:
- Session hijacking – Users could be logged into another user's session
- Authentication issues – Tokens or session IDs shared between users
- Privacy violations – User-specific preferences exposed to others
- Tracking problems – Analytics cookies assigned to wrong users
How It Works
Response is cached normally at the edge and served to all users requesting the same resource.
Response is passed through directly to the requesting user without caching. Each request fetches fresh from origin.