CDN and origin caching optimization: 12 strategies that actually work If you're watching your server costs climb while page load times disappoint users, your caching strategy probably needs attention. Poor caching configuration is often the hidden culprit behind sluggish applications and inflated infrastructure bills. This guide covers 12 practical caching optimizations for engineering teams running high-traffic applications, e-commerce platforms, or SaaS products where every millisecond matters. Match cache expiration times to actual content update patterns, not arbitrary defaults. Static resources like images and stylesheets can cache for weeks, while API endpoints need much shorter windows. # Long-term caching for static assets location ~* \.(jpg|jpeg|png|css|js)$ { expires 30d; add_header Cache-Control "public, immutable"; } # Short-term for API responses location /api/ { expires 5m; add_header Cache-Control "public, max-age=300"; } Use cache-control headers to manage both CDN and browser behavior separately. The s-maxage directive controls CDN caching independently from browser cache duration. # Daily-changing content Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=3600 # Frequently updated APIs Cache-Control: public, max-age=300, s-maxage=300, must-revalidate Prevent cache misses on critical pages by warming cache after deployments. Set up scripts that request key URLs immediately following cache purges or application updates. Build caching layers at your origin server using Redis or Memcached for database queries and computed values. This reduces database load even when CDN cache misses occur. Make cache invalidation part of your CI/CD pipeline, not a manual step. Use versioned asset URLs and selective purging for content that updates independently. # Automated purge in deployment curl -X PURGE "https://cdn.example.com/api/products/*" # Tag-based invalidation curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \ -H "Authorization: Bearer TOKEN" \ -d '{"tags":["product-data"]}' Track cache performance metrics for both CDN and origin layers. Target 80%+ hit ratios for static content and 50%+ for dynamic content. Use these numbers to identify misconfigured TTLs. When popular cached content expires on high-traffic sites, multiple simultaneous requests can overwhelm your origin. Implement request coalescing so only one request fetches fresh content while others wait. Cache page shells for long periods while dynamically inserting personalized sections using ESI. This works well for pages with both static layouts and user-specific content. Configure region-specific TTLs based on actual usage patterns. Content popular in certain regions should cache longer there while being cached less aggressively where it's rarely accessed. Set up cache bypass rules for authenticated users to prevent serving personal data to wrong users while still caching public content effectively. set $skip_cache 0; if ($http_cookie ~* "logged_in=true") { set $skip_cache 1; } location / { proxy_cache_bypass $skip_cache; proxy_no_cache $skip_cache; } Structure caching layers by cost efficiency: expensive CDN bandwidth for highest-traffic content, cheaper origin caching for medium traffic, and database caching for the long tail. Monitor cache hit ratios, response times, and origin load. Set alerts when metrics deviate from baseline performance to catch issues before users notice them. Start with TTL configuration, cache-control headers, and monitoring (practices 1, 2, and 6). These provide immediate visibility and control. Then integrate cache invalidation into your deployment process before tackling complex optimizations like ESI or geographic caching. Measure impact by tracking response times, server load, and bandwidth costs. Well-implemented caching typically reduces origin load by 60-80% and improves response times by 200-500ms for cached content. Assign cache performance ownership to specific team members and include hit ratios in regular performance reviews. Document your TTL decisions so the team understands the reasoning behind configurations. Originally published on binadit.com