CDN Optimization Template for Engineering Teams

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.

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.

`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.

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.

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.