A CDN (Content Delivery Network) caches your content at edge locations worldwide so users receive responses from a server physically close to them instead of routing every request back to your origin. The performance impact is significant: a user in Tokyo hitting an origin server in Virginia adds 150-200ms of round-trip latency on every request. A CDN edge in Tokyo reduces that to under 10ms.
But CDN configuration is rarely set-and-forget. Incorrect cache rules serve stale content to users. Missing cache-control headers mean the CDN passes every request through to the origin, defeating the purpose. Overly aggressive caching breaks authenticated or personalized responses. This template helps you define cache rules per content type, configure origin shielding, and set up monitoring to verify the CDN is actually delivering the expected performance gains.
Use this alongside the Caching Strategy Template for application-layer caching decisions. The API Performance Template helps you measure the latency improvements the CDN delivers. The Monitoring and Alerting Template covers alerting on CDN-specific metrics like cache hit ratio and origin error rate. The Technical PM Handbook discusses how PMs should factor geographic performance into product requirements.
When to Use This Template
You are setting up a CDN for the first time and need to define cache rules
Your CDN cache hit ratio is below 80% and you want to improve it
Users in specific regions report slower performance than others
You are expanding to a new geographic market and need edge presence
A site audit revealed inconsistent cache-control headers across your application
Origin server costs are high because the CDN is not offloading enough traffic
How to Use This Template
Start with the Content Inventory. Categorize every content type your CDN serves (static assets, HTML pages, API responses, media).
Define cache rules per content type. Set TTLs, cache-control headers, and vary conditions.
Configure origin shielding and failover. Reduce origin load by routing CDN cache misses through a shield POP.
Set performance benchmarks by region. Define target TTFB (Time to First Byte) for each major market.
Implement monitoring. Track cache hit ratio, bandwidth offload, and edge error rates.
Review quarterly. As your content mix and user geography shift, CDN configuration needs adjustment.
The Template
Content Inventory
Content Type
Path Pattern
Dynamic?
Personalized?
Avg Size
Monthly Requests
Current Cache Status
[Static assets (JS/CSS)]
[/static/*]
No
No
[X KB]
[X M]
[Cached / Not cached / Partial]
[Images]
[/images/*]
No
No
[X KB]
[X M]
[Cached / Not cached / Partial]
[HTML pages]
[/*]
Yes
No
[X KB]
[X M]
[Cached / Not cached / Partial]
[API responses]
[/api/*]
Yes
Yes
[X KB]
[X M]
[Cached / Not cached / Partial]
Cache Rules
Content Type
Cache-Control Header
CDN TTL
Browser TTL
Vary Header
Stale-While-Revalidate
Stale-If-Error
[Static assets]
[public, max-age=31536000, immutable]
[1 year]
[1 year]
[None]
[N/A]
[N/A]
[Images]
[public, max-age=86400]
[24h]
[24h]
[Accept]
[86400]
[86400]
[HTML pages]
[public, max-age=0, s-maxage=300]
[5 min]
[0 (always revalidate)]
[None]
[300]
[3600]
[API responses (public)]
[public, max-age=0, s-maxage=60]
[60s]
[0]
[Accept-Encoding]
[60]
[300]
[API responses (auth)]
[private, no-store]
[Do not cache]
[Do not cache]
[N/A]
[N/A]
[N/A]
Cache rule guidelines.
Static assets with hashed filenames. Cache for 1 year with immutable. The hash in the filename guarantees a new URL when the content changes.
Images without hashed names. Cache for 24 hours. Use stale-while-revalidate so users see the cached version while the CDN fetches the updated image in the background.
HTML pages. Use s-maxage (CDN TTL) separate from max-age (browser TTL). The CDN caches for 5 minutes. The browser always revalidates. This gives you control over freshness at the edge without stale browser caches.
Authenticated API responses. Never cache. Use private, no-store to prevent the CDN from serving one user's data to another.
Origin Shielding
Origin Region
Shield POP
Collapse Wait
Max Connections to Origin
[us-east-1]
[IAD (Washington DC)]
[100ms]
[500]
What origin shielding does. Without shielding, every CDN edge POP sends cache misses directly to your origin. With 50+ POPs worldwide, a cache expiration can generate 50+ simultaneous origin requests. A shield POP acts as a single point between the edge and origin, reducing origin load by 80-95%.
Geographic Performance Targets
Region
Target TTFB
Current TTFB
Nearest CDN POP
Users (%)
[North America]
[<50ms]
[X ms]
[Multiple]
[X%]
[Europe]
[<75ms]
[X ms]
[Multiple]
[X%]
[Asia-Pacific]
[<100ms]
[X ms]
[Multiple]
[X%]
[South America]
[<120ms]
[X ms]
[Multiple]
[X%]
Edge Logic Rules
Rule Name
Condition
Action
Purpose
[Strip query params on static]
Path matches /static/*
Remove query string before cache key
Prevent cache fragmentation from tracking params
[Redirect HTTP to HTTPS]
Scheme = http
301 redirect to https
Security + single cache key
[Add security headers]
All responses
Add HSTS, X-Frame-Options, CSP
Security headers at edge
[Bot rate limiting]
User-Agent matches bot pattern
Rate limit to 10 rps
Protect origin from aggressive crawlers
[Geo-redirect]
Country = [specific]
Redirect to localized domain
Serve localized content
Monitoring Dashboard
Metric
Target
Alert Threshold
Check Frequency
Cache hit ratio (overall)
[>85%]
[<70%]
[Every 5 min]
Cache hit ratio (static assets)
[>98%]
[<90%]
[Every 5 min]
Origin request rate
[
[>Y rps (2x normal)]
[Every 1 min]
Edge error rate (5xx)
[<0.1%]
[>0.5%]
[Every 1 min]
Bandwidth offload
[>80%]
[<60%]
[Hourly]
TTFB by region
[Per target above]
[>2x target]
[Every 5 min]
Purge Procedures
Scenario
Purge Scope
Method
Propagation Time
Who Can Execute
[Content update]
Single URL
[API call / CLI]
[<30s]
[Any developer]
[Template change]
Path prefix (/blog/*)
[API call / CLI]
[<2 min]
[Any developer]
[Emergency (security)]
Full cache
[API call / Dashboard]
[<5 min]
[On-call engineer, SRE lead]
[Deploy with cache-busted assets]
No purge needed
[N/A (hashed filenames)]
[N/A]
[N/A]
Filled Example: SaaS Application with Global Users
Content Inventory
Content Type
Path
Dynamic?
Personalized?
Avg Size
Monthly Reqs
Cache Status
JS/CSS bundles
/static/js/, /static/css/
No
No
180 KB
45M
Cached (hashed filenames)
Images/icons
/images/*
No
No
65 KB
28M
Cached
Marketing pages
/, /pricing, /blog/
Yes
No
42 KB
8M
Partially cached
App dashboard HTML
/app/*
Yes
Yes
15 KB
12M
Not cached
Public API (docs)
/api/v1/docs/*
Yes
No
8 KB
2M
Not cached (should be)
Auth API
/api/v1/auth/*
Yes
Yes
2 KB
6M
Not cached (correct)
Cache Rules Applied
Content Type
Cache-Control
CDN TTL
Browser TTL
Vary
SWR
JS/CSS bundles
public, max-age=31536000, immutable
1 year
1 year
Accept-Encoding
N/A
Images
public, max-age=86400
24h
24h
Accept
86400
Marketing pages
public, max-age=0, s-maxage=600
10 min
0
None
600
App dashboard
private, no-store
Do not cache
Do not cache
N/A
N/A
Public API docs
public, max-age=0, s-maxage=3600
1 hour
0
Accept-Encoding
3600
Auth API
private, no-store
Do not cache
Do not cache
N/A
N/A
Geographic Performance
Region
Target TTFB
Current TTFB
Nearest POP
Users
North America
<40ms
32ms
12 POPs
58%
Europe
<60ms
54ms
8 POPs
26%
Asia-Pacific
<80ms
95ms (needs improvement)
4 POPs
12%
South America
<100ms
88ms
2 POPs
4%
Action items for Asia-Pacific. Current TTFB of 95ms exceeds the 80ms target. Root cause: origin shielding routes APAC cache misses through IAD (Virginia), adding 180ms round trip. Fix: add a second shield POP in NRT (Tokyo) for APAC edge POPs. Expected improvement: TTFB drops to 45-55ms.
Key Takeaways
Use hashed filenames for static assets and cache them for 1 year with immutable. This is the highest-impact CDN optimization and eliminates unnecessary revalidation requests entirely.
Separate CDN TTL from browser TTL using s-maxage. This gives you control over edge caching without users being stuck with stale browser caches.
Never cache authenticated or personalized responses at the CDN. Serving one user's data to another is a privacy incident, not just a bug.
Enable origin shielding. Without it, every CDN POP sends cache misses directly to your origin, multiplying load by the number of edge locations.
Monitor cache hit ratio by content type, not just overall. A 90% overall hit ratio can mask a 20% hit ratio on your most important content type.
Strip tracking query parameters from cache keys for static assets. Parameters like ?utm_source=google create separate cache entries for identical content.
Frequently Asked Questions
What is a good CDN cache hit ratio?+
For static assets (JS, CSS, images), target 95%+ because these rarely change. For HTML pages, 70-85% is realistic because they change more frequently. For API responses, 50-80% depends on how personalized the data is. An overall cache hit ratio below 70% suggests misconfigured cache rules or too many personalized responses passing through the CDN.
How do I prevent the CDN from caching authenticated responses?+
Set `Cache-Control: private, no-store` on any response that contains user-specific data. At the CDN level, create a rule that bypasses caching for requests containing an Authorization header or session cookie. Test this by requesting the same authenticated endpoint from two different accounts and verifying they receive different responses.
What is stale-while-revalidate and when should I use it?+
`stale-while-revalidate` tells the CDN to serve an expired cached response immediately while fetching a fresh copy from the origin in the background. The user gets a fast response (from cache), and the next user gets a fresh response. Use it for content where a few seconds of staleness is acceptable (blog pages, product listings, documentation). Do not use it for financial data, inventory counts, or auth tokens.
How do I handle CDN cache during deployments?+
For static assets with hashed filenames, no purge is needed. The new deploy generates new filenames. For HTML pages cached at the edge, either purge the relevant paths after deploy or use short CDN TTLs (5-10 minutes) so stale pages expire quickly. Never rely on full cache purges as part of the deploy pipeline. They are slow and create a thundering herd on your origin.
Should PMs define CDN performance requirements?+
PMs should define the user experience requirements (page loads under 2 seconds in all target markets) and let engineering translate those into CDN configuration. If you are expanding to a new market (e.g., Southeast Asia), tell engineering the target user location and acceptable latency. They will determine whether new CDN POPs, origin shielding changes, or regional origins are needed.
Explore More Templates
Browse our full library of PM templates, or generate a custom version with AI.
