Image Caching Guide: Faster Pages on Every Repeat Visit

1. How Image Caching Works

When a browser fetches an image, the server responds with HTTP headers that tell the browser — and any CDN in between — how to store and reuse that response. On the next request for the same URL, the browser can serve the image from its local cache without making a network request at all.

There are two distinct layers of caching for images:

• Browser cache (client-side): The image is stored on the user's device. Repeat page loads serve it directly from disk — zero network time, zero server load.
• CDN cache (edge-side): The image is stored on CDN edge servers close to the user. Even on a first visit, the image is served from a nearby node rather than your origin server, dramatically reducing latency.

Both layers are controlled by HTTP response headers. Getting those headers right is the entire game.

The Cache Decision Flow

When a browser needs an image, it follows this decision tree:

1. Is it in the browser cache and still fresh? Serve immediately. No network request.
2. Is it in the browser cache but stale? Send a conditional request (with If-None-Match or If-Modified-Since) to revalidate. If unchanged, server returns 304 Not Modified — still no re-download.
3. Not in cache? Full request to CDN or origin. CDN may have it cached — if so, it responds without hitting your origin. Otherwise, origin serves it and CDN stores it for future requests.

2. Cache-Control Headers for Images

The Cache-Control header is the primary tool for controlling how images are cached. It supersedes the older Expires header and gives you precise control over caching behavior.

The Two Patterns You'll Actually Use

For images, there are really only two patterns worth knowing:

Key Directives Explained

• public: The response can be stored by any cache — browser, CDN, proxy. Required for CDN caching.
• private: Only the end user's browser may cache it. CDNs and proxies must not store it.
• max-age=N: Cache is considered fresh for N seconds. After that, the browser must revalidate.
• immutable: Tells the browser the resource will never change during its max-age window. Prevents unnecessary revalidation requests on reload. Use only with hashed/versioned URLs.
• must-revalidate: Once stale, the cache must not serve the resource without revalidating with the server (even if the server appears unreachable).
• no-cache: The cache must revalidate on every request before serving. The resource can still be stored and a 304 response avoids re-download.
• no-store: The response must not be stored anywhere. Use only for genuinely sensitive content — never for images.

3. Cache-Busting Strategies

The paradox of aggressive caching is that when you update an image, cached browsers won't see the new version until the TTL expires. Cache-busting solves this by making updated images appear at new URLs, forcing browsers to fetch fresh.

Method 1: Content Hashing (Recommended)

Append a hash of the file's contents to the filename. When the image changes, the hash changes, and the URL changes — guaranteed cache invalidation.

# Original
hero.webp

# After content hashing (Webpack, Vite, etc.)
hero.a3f9b2c1.webp   # v1
hero.d7e4f8a2.webp   # v2 (image changed, hash changed)

Most build tools (Webpack, Vite, Parcel) support content hashing out of the box via their output filename configuration.

Method 2: Version Query String

Append a version parameter to the URL. Simpler to implement manually, but some CDNs and proxies ignore query strings when caching — making it less reliable than filename hashing.

<!-- Query string versioning (less reliable with some CDNs) -->
<img src="/images/hero.webp?v=2" alt="Hero" />

Method 3: CDN Cache Purge

If you can't change the URL, most CDNs (Cloudflare, Fastly, CloudFront) offer an API to manually purge specific cached objects. This is useful for CMS-managed images where filenames are fixed.

4. CDN Edge Caching

A CDN caches your images on edge nodes distributed globally. When a user requests an image, it's served from the nearest node — often within milliseconds. Your origin server only receives the first request from each CDN region.

How CDNs Cache Images

CDNs respect your origin's Cache-Control headers by default. If your origin sends public, max-age=31536000, the CDN will cache the image for up to one year. Most CDNs also let you set edge cache TTLs independently of browser cache TTLs via their dashboard or configuration rules.

Vary Header and CDN Caching

If you serve different image formats based on the Accept header (e.g., WebP to Chrome, JPEG to Safari via server-side negotiation), you must include Vary: Accept in your response. Without it, a CDN might cache the WebP version and serve it to browsers that don't support WebP.

# When serving format-negotiated images server-side
Cache-Control: public, max-age=31536000, immutable
Vary: Accept
Content-Type: image/webp

5. ETags and Conditional Requests

When a cached image becomes stale (its max-age has passed), the browser doesn't automatically re-download it. Instead, it sends a conditional request to check whether the image has changed. If it hasn't, the server returns a lightweight 304 Not Modified response — no image bytes transferred.

ETag (Entity Tag)

An ETag is a unique identifier for a specific version of a resource. The server sends it with the original response; the browser sends it back in subsequent requests via If-None-Match.

# First request — server responds with ETag
HTTP/1.1 200 OK
Cache-Control: public, max-age=86400
ETag: "a3f9b2c1d7e4"
Content-Type: image/webp

# After max-age expires — browser revalidates
GET /images/hero.webp HTTP/1.1
If-None-Match: "a3f9b2c1d7e4"

# Image unchanged — server returns 304 (no body)
HTTP/1.1 304 Not Modified
Cache-Control: public, max-age=86400
ETag: "a3f9b2c1d7e4"

Most web servers (Nginx, Apache, Caddy) generate ETags automatically for static files. You generally don't need to configure them manually — but make sure they aren't being stripped by a reverse proxy misconfiguration.

Last-Modified as Fallback

If ETags aren't available, browsers fall back to Last-Modified / If-Modified-Since for revalidation. This is less precise than ETags (timestamp resolution is seconds) but still prevents re-downloading unchanged images.

6. Service Worker Image Caching

A Service Worker is a JavaScript file that runs in the background and can intercept network requests — including image requests. This gives you full programmatic control over caching that goes beyond what HTTP headers alone can provide.

When to Use Service Worker Caching for Images

• You need offline support — images must be available when the user has no connection.
• You want stale-while-revalidate behavior — serve cached immediately, then update in background.
• You need per-image cache policies that differ from your site-wide Cache-Control headers.

Cache-First Strategy (Best for Static Images)

Serve from cache if available; fall back to network. Ideal for images that rarely or never change.

const IMAGE_CACHE = 'images-v1';

self.addEventListener('fetch', event => {
  const { request } = event;

  // Only handle image requests
  if (!request.destination === 'image') return;

  event.respondWith(
    caches.open(IMAGE_CACHE).then(async cache => {
      const cached = await cache.match(request);
      if (cached) return cached; // Cache hit — serve immediately

      // Cache miss — fetch from network and store
      const response = await fetch(request);
      cache.put(request, response.clone());
      return response;
    })
  );
});

Stale-While-Revalidate (Best for Frequently Updated Images)

Serve cached immediately for speed, then fetch fresh in the background. The next request gets the updated version.

event.respondWith(
  caches.open(IMAGE_CACHE).then(async cache => {
    const cached = await cache.match(request);

    // Always fetch in background to refresh cache
    const networkFetch = fetch(request).then(response => {
      cache.put(request, response.clone());
      return response;
    });

    // Return cached immediately, or wait for network
    return cached || networkFetch;
  })
);

7. Server Configuration Examples

Here are ready-to-use cache header configurations for the most common web servers and platforms.

Nginx

# Long cache for versioned/hashed assets
location ~* \.(webp|avif|jpg|jpeg|png|gif|svg|ico)$ {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable";
  access_log off;
}

# Shorter cache for non-versioned images (e.g. CMS uploads)
location /uploads/ {
  expires 7d;
  add_header Cache-Control "public, max-age=604800, must-revalidate";
}

Apache (.htaccess)

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp   "access plus 1 year"
  ExpiresByType image/avif   "access plus 1 year"
  ExpiresByType image/jpeg   "access plus 1 year"
  ExpiresByType image/png    "access plus 1 year"
  ExpiresByType image/gif    "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(webp|avif|jpe?g|png|gif|svg|ico)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Cloudflare (Cache Rules)

In Cloudflare's dashboard under Caching → Cache Rules, create a rule matching http.request.uri.path matches "\.(webp|avif|jpg|jpeg|png|gif|svg)$" with Edge Cache TTL set to 1 year. Enable Browser Cache TTL to respect your origin's Cache-Control header.

Vercel / Next.js

{
  "headers": [
    {
      "source": "/(.*)\\.(?:webp|avif|jpg|jpeg|png|gif|svg|ico)",
      "headers": [
        {
          "key": "Cache-Control",
          "value": "public, max-age=31536000, immutable"
        }
      ]
    }
  ]
}

8. Common Image Caching Mistakes

• 1

  Setting no-store or no-cache on all responses

  Applying a global security header like Cache-Control: no-store to all routes prevents images from being cached at all. Always scope restrictive cache headers to sensitive routes (auth, user data) and use aggressive caching for static assets.

• 2

  Using long max-age without cache-busting

  Setting max-age=31536000 on non-versioned URLs means users can be stuck with stale images for up to a year after you update them. Always pair long TTLs with content-hashed filenames or ensure a CDN purge workflow is in place.

• 3

  Omitting the public directive

  Without public in your Cache-Control header, CDNs may refuse to cache the response. By default, responses that include cookies or authorization are treated as private. Always explicitly add public for images served to all users.

• 4

  Relying on query string cache-busting with a CDN that ignores query strings

  Some CDN configurations (and older proxies) cache based on the path only, ignoring query strings. hero.jpg?v=2 may be served from the hero.jpg?v=1 cache. Use filename-based versioning for guaranteed cache invalidation across all caches.

• 5

  Serving different formats at the same URL without Vary: Accept

  If your server sends WebP to Chrome and JPEG to Safari at the same URL without Vary: Accept, a CDN may cache the WebP and serve it to Safari users. Always set Vary: Accept when doing server-side format negotiation — or use separate URLs per format via <picture>.

• 6

  Not verifying cache headers are actually being sent

  Always verify with browser DevTools (Network tab → select image → Response Headers) or curl -I https://yoursite.com/image.webp. It's common for CDNs, reverse proxies, or frameworks to strip or override cache headers set at the origin.

9. Full Image Caching Checklist

• ✓
  All images served with Cache-Control headers. Verified via DevTools or curl -I on actual image URLs.
• ✓
  Versioned/hashed image URLs use max-age=31536000, immutable. Build tool configured to append content hashes to image filenames.
• ✓
  Non-versioned URLs use a shorter TTL (1–7 days) with must-revalidate. CMS upload paths, profile images, etc.
• ✗
  No no-store or missing cache headers on image routes. Checked that global security headers don't apply to static asset paths.
• ✓
  public directive is set on all images served to anonymous users so CDNs can cache them.
• ✓
  CDN is configured to cache images. Edge cache TTL set. CDN is not in pass-through mode for image paths.
• ✓
  ETags or Last-Modified headers are present for revalidation of non-versioned images. Not stripped by proxy.
• ✓
  Format-negotiated images include Vary: Accept — or format switching is handled via <picture> with separate URLs per format.
• ✓
  Cache-busting workflow exists for updating images. Either content-hashed filenames, or a CDN purge script/automation is in place.
• ✓
  Verified in a real browser. DevTools → Network → Disable cache OFF → reload → check image Status shows 200 first load and 304 or from disk cache on repeat.

10. Frequently Asked Questions

• How long should images be cached?

  Images at content-hashed URLs (e.g. hero.a3f9b2.webp) should be cached for 1 year — max-age=31536000. Since the URL changes whenever the image changes, there's no risk of serving stale content. For images at static, non-versioned URLs (CMS uploads, profile photos), use 1–7 days with must-revalidate to balance freshness and performance.

• What is cache-busting for images?

  Cache-busting is the practice of changing an image's URL whenever its content changes, forcing browsers and CDNs to fetch the new version. The most reliable method is content hashing: appending a hash of the file's contents to the filename (e.g. hero.a3f9b2.webp). When the image changes, the hash changes, the URL changes, and every cache treats it as a new resource.

• Does image caching affect SEO?

  Yes, significantly. Properly cached images improve page load speed on repeat visits, which directly improves LCP — a Core Web Vital and Google ranking signal. Google's field data (Chrome User Experience Report) captures repeat visits, so caching improves your actual ranking score. Additionally, faster repeat load times reduce bounce rates, which correlates with better organic performance.

• What Cache-Control header should I use for images?

  For versioned/hashed URLs: Cache-Control: public, max-age=31536000, immutable. The immutable directive prevents browsers from revalidating during the max-age window, saving unnecessary round trips. For non-versioned URLs: Cache-Control: public, max-age=86400, must-revalidate. Never use no-store on images — it forces a full re-download on every single page load.

• What is the difference between browser cache and CDN cache?

  Browser cache stores images on the user's local device — repeat page loads serve them with zero network time. CDN cache stores images on edge servers close to users — even on first visit, the image travels a short distance from a nearby CDN node rather than your origin server. Both are controlled by Cache-Control headers and both are important. They work together: CDN reduces latency on first visit; browser cache eliminates network latency on repeat visits.

• Can I cache images with a Service Worker?

  Yes. A Service Worker intercepts image fetch requests and can serve them from the Cache Storage API, enabling offline support and custom per-image caching strategies beyond what HTTP headers alone allow. Common strategies are Cache-First (always serve from cache if available) and Stale-While-Revalidate (serve cached immediately, refresh in background). For most projects, Google's Workbox library makes Service Worker image caching straightforward to implement.

• How do I check if my images are being cached?

  In Chrome DevTools: open the Network tab, make sure "Disable cache" is unchecked, reload the page, click an image request, and inspect the Response Headers for Cache-Control, ETag, and Last-Modified. On a second load, the Status column should show 304 (revalidated) or 200 (from disk cache) / 200 (from memory cache). You can also run curl -I https://yoursite.com/image.webp to inspect headers directly.