CDN & Caching for Images: Headers, Versions, and Cache Busting

About the Author

Quick Image Tools Editorial — Practical image workflows for the modern web. This article, “CDN & Caching for Images: Headers, Versions, and Cache Busting,” was prepared by our in‑house team and peer‑reviewed for accuracy.

Questions? Contact us.

Published: 2025-11-07 • Last updated: 2025-11-07

TL;DR

Set long Cache-Control for immutable image URLs, use file hashing for cache busting, and push critical assets via CDN close to users.

Caching Strategy

  • Immutable assets: Cache-Control: public, max-age=31536000, immutable
  • Versioning: Add a hash to the filename (e.g., hero.3f29a.webp).
  • Invalidation: Only purge on version changes, not every deploy.

Responsive Delivery

Use srcset/sizes to avoid shipping overly large assets to small screens. Pair with WebP for further byte savings.

Netlify Tips

On Netlify, set caching headers in _headers or netlify.toml. Verify in DevTools → Network. Your live site: https://quickimagetools.netlify.app.

Checklist

  • Immutable caching for static images.
  • Versioned filenames for safe long TTLs.
  • Preload only the single LCP image.

Last updated: 2025-11-07

Caching strategy for image-heavy sites

A CDN helps when users are far from your origin server, but caching rules determine whether images are served quickly or revalidated too often. Strong caching headers are especially important for assets that rarely change.

If you update an image frequently, use versioned filenames (or query strings) so browsers can cache aggressively without showing stale content.

How caching interacts with image edits

After you optimize an image, caching determines whether visitors actually receive the new file. If you replace a filename without versioning, some users may keep the old image until cache expiry.

For image-heavy pages, good caching can matter as much as compression—bytes saved are great, but bytes avoided are even better.

Cache-busting without chaos

When you update an image but keep the same filename, some visitors will keep seeing the old version due to caching. Versioned filenames solve this cleanly: change the name when the content changes.

For sites with many images, this prevents hours of confusion where your dashboard shows a new image but users keep loading the cached one.

One rule that prevents “stale image” headaches

If the picture changes, change the filename. Versioning is the simplest strategy because it works with every cache and every browser.

For teams, this also avoids confusion where some people see the new asset and others see the old one for hours or days.

Updating images without confusing visitors

Caching is great until you change an image and some people still see the old one. Versioned filenames solve this cleanly because caches treat each version as a new asset. If you replace files in-place, you can get a mixed experience where half your audience sees the update and half doesn’t.

If you run promotions, always version promo graphics so the swap is immediate and predictable.

Photographer angle: portfolio updates need versioned filenames

If you swap a hero image or featured work, caches can keep showing the old shot. Changing the filename when you update the photo ensures visitors see your latest work immediately.

Simple update rule for teams

When an asset changes, rename it. That policy avoids debates about cache headers and instantly resolves “I still see the old image” complaints.

When updates don’t show up

The simplest way to make updates appear instantly is versioned filenames. If the image changes, rename it. Caches will treat it as a new file, so visitors won’t get stuck with the old version.

This is especially important for featured work and hero images on portfolios.

A rule for updating images safely

If you update an image and visitors still see the old version, you’re dealing with caching. The simplest rule: if the pixels change, change the filename.

This prevents confusion and makes updates appear immediately without relying on cache purges.

Cache-Control header reference for images
ScenarioRecommended headerCache duration
Versioned/hashed filenamespublic, max-age=31536000, immutable1 year
Generic filenames, may changepublic, max-age=8640024 hours
Frequently updated imagespublic, max-age=3600, must-revalidate1 hour
User-specific imagesprivate, max-age=36001 hour (browser only)
Never cacheno-store0

Frequently Asked Questions

Why does my updated image still show the old version?

When you update an image file at the same URL, browsers and CDNs may serve the cached version for hours, days, or even weeks depending on the Cache-Control headers. The browser has no way to know the file changed because the URL is the same. The reliable fix is to change the image filename when you update it — this creates a new URL that has never been cached. Common patterns: append a version number (logo-v2.png), a hash of the file contents (logo-abc123.png), or a timestamp (logo-20250301.png).

What Cache-Control headers should images have?

For images with version/hash in the filename (immutable assets): Cache-Control: public, max-age=31536000, immutable — this tells browsers and CDNs to cache for one year and never revalidate. For images served at generic filenames that might change: Cache-Control: public, max-age=86400 (24 hours) with an ETag for conditional revalidation. The immutable directive tells modern browsers they never need to send a revalidation request, reducing network round-trips even during hard refreshes.

What is cache busting and when should I use it?

Cache busting is the practice of changing an asset URL when its content changes, forcing browsers and CDNs to fetch the new version. For images, this means renaming the file or appending a query string (?v=2) when content changes. Build tools like webpack, Vite, and Parcel automatically add content hashes to asset filenames. For manually managed images, establish a naming convention (image-v2.jpg or image-[hash].jpg) and update all references when the file changes.

How do CDNs speed up image delivery?

CDNs (Content Delivery Networks) cache copies of your images at edge servers located around the world. When a user requests an image, it's served from the nearest edge server rather than your origin server — reducing latency by 50–200ms or more depending on geographic distance. CDNs also handle traffic spikes without origin server load. For image-heavy sites, a CDN is one of the highest-impact performance improvements available. Popular options: Cloudflare (has a free tier), AWS CloudFront, Fastly, and image-specific CDNs like Cloudinary and imgix.

How do I implement image caching on Netlify?

Netlify uses a _headers file to set custom HTTP headers. For immutable versioned assets: add a rule in _headers specifying Cache-Control: public, max-age=31536000, immutable for your image paths. For unversioned images, set a shorter max-age with stale-while-revalidate. Note that Netlify's CDN automatically caches static assets — the _headers file controls browser caching and downstream CDN behavior. When deploying image updates, Netlify's deploy-based cache invalidation automatically clears the CDN cache for changed files.

Cache-Control Recipes

# Immutable static images
Cache-Control: public, max-age=31536000, immutable

Pair with filename hashing, e.g., hero.a1b2c3.webp.

Versioning Strategy

Netlify Headers Example

/*.(webp|jpg|png)
  Cache-Control: public, max-age=31536000, immutable

/hero*.webp
  Link: <https://quickimagetools.netlify.app/images/hero.webp>; rel=preload; as=image

Operational Checklist

  1. Confirm cache headers in DevTools.
  2. Validate cache hits from multiple regions with your CDN panel.
  3. Document a rollback path for critical images.

Headers That Scale

/*.(webp|jpg|png)
  Cache-Control: public, max-age=31536000, immutable

Immutable caching is safe only when you version filenames.

Version Manifest Notes

  • Store a JSON manifest mapping logical names → hashed files.
  • Purge only changed assets on deploy; never blanket‑purge.
  • Keep a rollback manifest for the previous release.

Verify From Edge

Test from multiple regions via your CDN’s trace tool. Confirm cache hit/miss and TTL. Inspect response headers in DevTools.

ETag vs. Cache-Control

  • Cache-Control controls freshness at the client/CDN.
  • ETag helps conditional requests; with immutable assets + versioning, you’ll rarely need revalidation.

Safe Purge Policy

  1. Version filenames; avoid global purges.
  2. Invalidate only changed assets paths.
  3. Automate manifest diff to keep purge minimal.

Edge Debugging Checklist

  • Check headers with curl/DevTools.
  • Verify cache hits across regions.
  • Ensure origin isn’t sending conflicting headers.

Frequently Asked Questions

Should I use immutable caching for images?

Yes—if you version filenames. Use Cache‑Control: immutable with long max‑age.

Do I need to purge the whole CDN on deploy?

No. Invalidate only the paths that changed (based on a manifest).

How do I verify caching is working?

Check response headers and cache hit/miss in DevTools and your CDN panel across regions.