The fastest file doesn't load at all

Image optimization is mostly about making things smaller. But there's an even more effective lever: an image the visitor already has doesn't need loading at all. That's exactly what browser caching does — and it makes repeat visits and page changes noticeably faster, because the logo, the icons, and recurring images come from local storage instead of the server.

How it works

When the browser loads an image, it puts it in its cache (local temporary storage). The next time the same image is needed — the subpage with the same header logo, tomorrow's second visit — it uses the local copy instead of asking the server again. No network trip, no waiting, no data usage. How long, and whether at all, is controlled by the server via HTTP headers sent with the image.

The most important header: Cache-Control

The central directive is Cache-Control with a max-age value in seconds — it tells the browser how long it may use the image without asking:

Cache-Control: public, max-age=31536000

The 31536000 is one year in seconds. For static images that never change (a photo in a blog post, a fixed logo), a very long cache time is ideal: load once, use for a year. It's one of the building blocks of fast pages.

The big trap: the image changes

Long cache times have a catch: if you swap an image (new logo, corrected graphic) under the same file name, the returning visitor keeps seeing the old version — their browser still considers it valid. That's the classic “why do I see the old logo?” effect.

The solution: cache busting

The trick is cache busting — give the new version a new name so the browser recognizes it as a new file:

  • New file name: logo.v2.png instead of logo.png.
  • Version parameter: logo.png?v=2.
  • Hash in the name: logo.8f3a1c.png — change the content, change the hash.

That gets you both: very long cache times and instant updates when something changes. The old file simply expires, the new one loads fresh.

Do you have to handle this yourself?

Often not directly: modern hosting services, CDNs, and frameworks set sensible cache headers for images automatically — including cache busting via hashed file names (which is why build files are often named image.a1b2c3.jpg). But if you self-host a simple site, check whether static images are even served with a cache time — without it, every visitor reloads every image on every visit. Together with lazy loading and compression, caching is one of the three big image-performance levers.

In short

  • Caching means a repeat visitor doesn't reload images.
  • Cache-Control: max-age sets how long — long for static images.
  • Changed an image? Rename it (cache busting), don't reuse the name.
  • Many hosts/CDNs handle this automatically with hashed names.