CDN Cache Strategy Guide

Cache strategy basics

CDN caching is not really about storing pages for the sake of it. It is about moving content closer to the user so that requests can be served quickly without always hitting the origin server. For most websites, the bottleneck is not raw compute power but the round-trip time of requests, the cost of repeated asset delivery, and the number of cache misses.

Do not cache everything the same way

The most common mistake is treating every response as if it should be cached for a long time. HTML pages, customer-specific content, and promotional pages usually need short or no caching. Static assets such as images, CSS, and fonts can usually stay cached much longer.

Cache-Control headers

# Strong cache: browser can reuse the asset without rechecking immediately
location ~* \.(jpg|png|webp)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# Weak cache: browser still revalidates before reuse
location ~* \.html$ {
    add_header Cache-Control "public, max-age=0, must-revalidate";
}

# No cache: sensitive pages and admin routes always hit origin
location /admin/ {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
}

If you use Cloudflare, Fastly, or Akamai, caching is affected not just by response headers but also by URL structure, request method, cookies, and query parameters. A harmless-looking ?v=1.2 parameter may create extra cache fragments and reduce hit rate.

Cache by file type

A practical rule of thumb

• Cache static assets aggressively;
• Use short TTLs for pages and APIs;
• Avoid caching personalized content unless you have a very controlled strategy.

Cache purge

Purge behavior matters as much as the initial rules. If you deploy a new version of your site, replace images, or fix incorrect content, stale files can remain on edge nodes for a while.

Use the CDN API to purge specific URLs or everything after deployment.

Optimization tips

# Strip tracking parameters to reduce cache fragmentation
if ($args ~* "(utm_|fbclid|gclid)") {
    set $args '';
}

1. Keep URLs consistent — avoid www vs non-www duplication;
2. Use a reasonable TTL — very short TTLs make caching less effective;
3. Version assets — use hashed filenames such as style.a1b2c3.js;
4. Do not attach cookies to static assets;
5. Separate dynamic content from static content when possible.

Common setup examples

WordPress

Cache policy:
- /wp-content/uploads/*       → 30 days
- /wp-includes/*.css,*.js     → 365 days
- /wp-admin/*                 → no cache
- /*.php                      → no cache
- HTML pages                  → 1 hour

Static site

Cache policy:
- /*.html                     → 1 hour
- /_next/static/*            → 365 days
- /assets/*                  → 365 days
- /images/*                  → 30 days
- /fonts/*                   → 365 days

API service

Cache policy:
- GET /api/public/*          → 5 minutes
- GET /api/prices            → 1 hour
- POST/PUT/DELETE/*         → no cache
- GET /api/user/*            → no cache

4. Common mistakes and troubleshooting checklist

The most common caching mistake is not setting a TTL too short, but mixing different content types under the same rules. Homepage branding assets, product images, API responses, and login pages should not all be treated the same way. A common symptom is that a new stylesheet is deployed but users still see an old version of the page. That usually means the CDN is still serving stale content or the edge node did not receive the updated response headers.

When troubleshooting, check the response headers first, confirm that the URL structure is stable, and verify whether personalized requests with cookies are causing static resources to be treated as dynamic. For most sites, separating static assets from dynamic content is more effective than simply increasing the TTL.

Reference: Cloudflare Cache Rules documentation https://developers.cloudflare.com/cache/; MDN Cache-Control reference https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control

If you are optimizing website performance, caching is often a better first move than upgrading servers because it improves the user experience without adding much complexity.