What is CDN Cache, Invalidation and Performance?
CDN cache stores copies of content on edge servers close to users, reducing latency and load on the origin server. Cache invalidation is the mechanism to update or remove that content before its natural expiration. The combination of effective caching and precise invalidation determines how fast and consistent your content is delivered.
Last updated: 2026-06-18
How CDN Cache Works
When a user requests content, the CDN checks if a copy exists at the nearest edge server. If it exists and is valid, it serves directly (cache hit). If it doesn’t exist or has expired, it fetches from origin and stores for future requests (cache miss).
┌─────────────────────────────────────────────────────────────────┐│ User Request │└───────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌─────────────────┐ │ CDN Edge │ │ Cache Check │ └────────┬────────┘ │ ┌─────────────┴─────────────┐ │ │ ▼ ▼ ┌───────────┐ ┌───────────┐ │ Cache Hit │ │ Cache Miss│ │ (Serve) │ │ (Fetch) │ └─────┬─────┘ └─────┬─────┘ │ │ │ ▼ │ ┌───────────────┐ │ │ Origin │ │ │ Server │ │ └───────┬───────┘ │ │ │ ▼ │ ┌───────────────┐ │ │ Store in │ │ │ Edge Cache │ │ └───────┬───────┘ │ │ └───────────┬───────────────┘ │ ▼ ┌─────────────┐ │ Response │ │ to User │ └─────────────┘Cache Strategy Comparison
| Strategy | How It Works | When to Use |
|---|---|---|
| TTL (Time-to-Live) | Content expires after defined time | Static content, low change frequency |
| Stale-While-Revalidate | Serves stale, updates in background | High availability, stale tolerance |
| Stale-If-Error | Serves stale if origin fails | Resilience, fallback |
| Cache-Aside | Application manages cache explicitly | Dynamic APIs, full control |
| Write-Through | Updates cache on write | Critical data, immediate consistency |
HTTP Cache Control Headers
Cache-Control
| Directive | Meaning | Example Use |
|---|---|---|
max-age=3600 | Cache valid for 3600 seconds | Versioned assets |
s-maxage=3600 | TTL for CDN (different from browser) | CDN-specific |
public | Can be cached by anyone | Public content |
private | Browser cache only | User data |
no-cache | Revalidate before serving | Sensitive content |
no-store | Do not cache | Sensitive data |
stale-while-revalidate=86400 | Serve stale for 24h while revalidating | High availability |
stale-if-error=3600 | Serve stale if origin returns error | Resilience |
ETag and Last-Modified
Request: If-None-Match: "abc123" If-Modified-Since: Wed, 18 Jun 2026 10:00:00 GMT
Response (not modified): HTTP/1.1 304 Not Modified
Response (modified): HTTP/1.1 200 OK ETag: "def456" Last-Modified: Wed, 18 Jun 2026 12:00:00 GMT Cache-Control: max-age=3600Cache Invalidation
Invalidation Methods
| Method | Advantages | Disadvantages |
|---|---|---|
| TTL expiration | Simple, automatic | Stale until expired |
| Purge (manual/API) | Immediate control | Requires infrastructure |
| Soft purge | Updates in background | No immediate consistency guarantee |
| Webhook/Event-driven | Automated | Implementation complexity |
| Surrogate keys | Selective invalidation | Requires specific configuration |
Purge API Example
# Full purgecurl -X PURGE https://cdn.example.com/*
# Purge by surrogate keycurl -X PURGE -H "Surrogate-Key: product-123" https://api.cdn.example.com/purge
# Soft purge (allows stale while revalidating)curl -X PURGE -H "Fastly-Soft-Purge: 1" https://cdn.example.com/pagePerformance Metrics
Cache Hit Ratio
Cache Hit Ratio = (Cache Hits / Total Requests) × 100
Example:- Cache Hits: 85,000- Cache Misses: 15,000- Total: 100,000- Hit Ratio: 85%Benchmarks by content type:
| Content Type | Expected Hit Ratio | Typical TTL |
|---|---|---|
| Static assets (CSS, JS, images) | 95-99% | 1 year (versioned) |
| Static pages (HTML) | 80-95% | 1-24 hours |
| Public APIs | 70-90% | 1-60 minutes |
| Authenticated APIs | 30-60% | 0-5 minutes |
| Streaming/Dynamic | 10-40% | 0-10 seconds |
Time to First Byte (TTFB)
| Scenario | Expected TTFB |
|---|---|
| Cache hit at edge | < 50ms |
| Cache miss (origin responding) | 100-500ms |
| Cache miss (slow origin) | 500-2000ms |
| Stale-while-revalidate | < 50ms (stale) + background revalidation |
Latency by Region
Typical latency with CDN vs without CDN:
| User Region | Without CDN | With CDN | Improvement |
|---|---|---|---|
| Same datacenter as origin | 20-50ms | 20-50ms | 0% |
| Same continent | 100-300ms | 20-80ms | 60-80% |
| Different continent | 200-800ms | 30-100ms | 75-90% |
Signs of Cache Problems
- Cache hit ratio below 70% for static content
- TTFB consistently above 200ms for cached pages
- Traffic spikes at origin during events
- Users reporting stale content
- High origin egress costs
- 502/504 errors during mass invalidations
Common Mistakes and Fixes
Mistake: TTL too short for versioned assets
Fix: Assets with hash in name can have 1 year TTL (max-age=31536000)
Mistake: Purge in infinite loop (invalidate → revalidate → invalidate) Fix: Implement debounce or cooldown between invalidations
Mistake: Conflicting Cache-Control (max-age + no-cache)
Fix: Use consistent directives, no-cache requires revalidation always
Mistake: Ignoring query strings in cache Fix: Configure CDN to normalize or ignore query strings when appropriate
Mistake: Not configuring stale handlers
Fix: Always configure stale-if-error for resilience
Use Cases
E-commerce with Dynamic Inventory
Product pages: TTL 5 minutes + stale-while-revalidate 1 hour. Inventory API: TTL 30 seconds. Manual purge when updating price or stock.
News Portal
Articles: TTL 1 hour + stale-while-revalidate 24 hours. Breaking news: immediate purge via webhook. Homepage: TTL 5 minutes + purge on publish.
SaaS Dashboard
Public data (plans, features): TTL 24 hours. User dashboard: private, no-store. Metrics API: TTL 1 minute + stale-if-error 5 minutes.
Video Streaming
Video segments: TTL 1 year (immutable). Playlist/manifest: TTL 10 seconds. Geo-blocking: evaluated at edge, no cache.
Frequently Asked Questions
What is the difference between TTL and cache invalidation? TTL (Time-to-Live) defines how long content stays in cache before expiring automatically. Invalidation removes or updates content before TTL expires, ensuring immediate consistency.
When should I use stale-while-revalidate? Use when high availability is more important than immediate consistency. Users get stale content instantly while CDN fetches the updated version in background.
How to calculate ideal cache hit ratio? Monitor hit ratio by content type. Static assets should be 95%+. Dynamic content varies. If hit ratio drops, check TTL, access patterns, and query string configuration.
What is surrogate key and when to use it? Surrogate key is an additional identifier for content groups. Allows invalidating multiple URLs with a single key. Use when related content needs to be updated together (e.g., all posts in a category).
Can private cache be stored in CDN?
Not by default. Cache-Control: private indicates only browser can cache. CDNs respect this directive. For shared cache with access control, use public with authentication at edge.
How to avoid accidental full cache purge? Implement protections: require confirmation for broad purges, limit purge frequency, use surrogate keys for selective invalidation, monitor and alert on suspicious purges.
What is the difference between PURGE and BAN? PURGE removes content from cache immediately. BAN marks content as invalid but may serve stale until revalidation. PURGE is more aggressive, BAN is more gradual.
How to handle cache for authenticated APIs?
Use Cache-Control: private or no-store for user-specific data. For data that can be cached per user, use Vary: Authorization headers or cache keys that include user ID.
Is CDN cache the same as browser cache?
No. CDN cache stores on edge server, serving multiple users. Browser cache is local on user’s device. CDNs use s-maxage for their cache, browsers use max-age.
How to configure cache for Single Page Applications?
HTML (index.html): no-cache or short TTL (always revalidates). Versioned JS/CSS: long TTL (1 year). APIs: TTL by criticality. SPA needs to revalidate HTML to get new chunks.
How This Applies in Practice
Well-configured CDN cache reduces latency by 60-90% and origin load by 70-95%. The cost of invalidation (purges, webhooks) is offset by bandwidth savings and better user experience.
Configure aggressive TTLs for immutable content, stale handlers for resilience, and selective invalidation for changing content. Monitor hit ratio and TTFB continuously. Adjust TTLs based on real access patterns, not assumptions.
How to Implement with Azion
Azion offers complete cache control at the edge:
- Edge Cache: Configure TTLs, stale handlers, and path-based rules
- Edge Functions: Implement custom cache logic in JavaScript/Wasm
- Cache API: Program invalidations via GraphQL or REST API
- Real-Time Metrics: Monitor hit ratio, TTFB, and volume by path
Typical Azion configuration:
Rules Engine:- If: Path matches /static/* Then: Cache TTL = 31536000 (1 year)
- If: Path matches /api/* Then: Cache TTL = 60, stale-while-revalidate = 3600
- If: Path matches /page/* Then: Cache TTL = 300, stale-if-error = 86400Learn more in the Azion Serverless Applications documentation.
Related Resources
Sources:
- RFC 7234. “Hypertext Transfer Protocol (HTTP/1.1): Caching.” IETF. 2014.
- CDN Planet. “Cache Hit Ratio Benchmarks.” 2024.
- HTTP Archive. “Web Almanac 2024: Caching.” 2024.