Image Delivery Cache-Control and CDN Invalidation 2025 — Fast, Safe, Reliable Updates

TL;DR

• Filename versioning is strongest. CDN purging is last resort
• Unify strategy: either immutable + long-lived or short-lived + SWR
• Clear separation between changing HTML and unchanging images

Internal links: INP-Focused Image Delivery Optimization 2025 — Safeguard User Experience with decode/priority/script coordination, Responsive Image Design 2025 — srcset/sizes Practical Guide, P3 Images Delivery Guide 2025 — sRGB Fallback and Device Testing Procedures, CDN Edge Resizing Pitfalls 2025 — The Triangle of Upscaling/Cache/Quality

Cache Models (3 Types)

1. immutable long-lived + versioning (recommended)

   • Cache-Control: public, max-age=31536000, immutable
   • Changes expressed through filename hashes (e.g., logo.abcd1234.png)
   • CDN purging only for emergencies. Update HTML references to new URLs

2. Short-lived + stale-while-revalidate (SWR)

   • Cache-Control: public, max-age=60, stale-while-revalidate=86400
   • Immediate delivery on first request, background update. Suitable for news or frequently updated thumbnails

3. Validation-based (ETag/Last-Modified focused)

   • Limited to cases where update frequency is low but versioning is difficult. Heavy 304 usage has header round-trip costs

Implementation Points

• Cache-Control: public, max-age=31536000, immutable + filename hashing
• SWR for static images where immediate initial render/background updates fit

ETag/Last-Modified usage:

• Generally unnecessary with immutable strategy (new URL = always fresh)
• Can combine ETag with SWR/short-lived for bandwidth savings. Consider generation cost/distributed consistency

Versioning Strategy

• Use content addressing (hashes) to make URLs immutable → minimize CDN purge frequency
• Clear separation between changing HTML and unchanging images
• Limit format negotiation to Vary: Accept only, handle DPR via URL parameters

Hash Granularity

• Recommend per-file content hashes over shared build IDs (prevents mis-purging/excessive invalidation)
• For dynamic transformations (resize/format), normalize request parameters (w, q, fmt, dpr) order and include in cache key

Systematic Purging

• Adopt surrogate keys per entity, specify batch changes via manifest
• Background warmup after purging (prefetch representative sizes)

Surrogate Key Examples

• sk:article:12345 (all thumbnails tied to article ID)
• sk:logo (brand logo all sizes)
• Manifest: article:12345 -> [/thumbs/a1.., /thumbs/a2..]

Warmup

• Prefetch popular route representative widths (e.g., 320/480/640/960)
• For edge transformation, maximize cache efficiency with noUpscale and rounding (limit variant count) (related: CDN Edge Resizing Pitfalls 2025 — The Triangle of Upscaling/Cache/Quality)

Common Failure Points

• HTML updated but old URL referenced somewhere → Cache residue. Automate search/replace + idempotent purge execution
• Transform URL parameter order varies → Cache fragmentation. Server-side normalization
• Too many Vary headers → Cache effectiveness lost. Accept only sufficient, DPR to URL

FAQ (Operational Decisions)

• Q. Should everything be immutable?
  • A. YES for most static images. Frequently updated thumbnails/dynamic generation can use SWR + short-lived effectively
• Q. CDN purging is slow/ineffective
  • A. Combine surrogate key operations with warmup. Worst case: filename changes for reliable switching
• Q. Image CDN 'auto-transformation' bloats cache keys
  • A. Limit and round allowed parameters. Fixed buckets for w, presets only for q

Checklist

• [ ] Enforce immutable URLs/versioning
• [ ] Manifest-driven purging, minimize manual ad-hoc
• [ ] Warmer/monitoring operational

Additional checks:

• [ ] Transform parameter normalization (order/range/rounding)
• [ ] Fix Vary to Accept only, DPR to URL
• [ ] Content-based hashing, avoid shared build IDs