All articles
Engineering

Caching vehicle images: a practical strategy

The fastest and cheapest image request is the one you never make twice. Cache layers, keys and invalidation for vehicle imagery, without the folklore.

Robin AshfordOctober 5, 20266 min read
Blog hero: caching-vehicle-images

Vehicle imagery is a caching dream that teams routinely treat as a streaming problem. The images change rarely, the access patterns repeat heavily, and the identifiers are stable, which means nearly every request after the first is avoidable. Getting the layers right cuts latency, bills and origin dependence in one move, and the strategy fits on a page.

The three layers, and what each owns

  1. The browser and app cache, owning repeat views within a session and beyond, driven entirely by the cache headers you let through
  2. Your CDN or storage layer, owning your whole audience's repeats and your independence from any origin
  3. The provider's CDN, owning global distribution and the cold start you did not want to pay for
Blog inline: caching-vehicle-images

Most integrations under use the middle layer, which is the one that buys autonomy. Serving vehicle images from your own bucket or CDN, refilled from the provider on catalogue changes, means your critical path never waits on an external origin, and your bill stops scaling with page views.

Keys: stable IDs or nothing

Cache keys built from search strings rot; keys built from identifiers last. The pattern that works keys every stored image on the stable catalogue ID plus the render parameters, angle, colour, size and format, exactly the shape the API exposes. VINs resolve to those IDs once, at ingest, and everything downstream speaks IDs. When a marketing search or a plate lookup produces the vehicle, it produces the same ID, and the cache hits regardless of the path that led there.

Invalidation without drama

The classic hard problem stays easy here because vehicle imagery changes on catalogue rhythm, not user rhythm. Refresh on model year updates and catalogue corrections, which arrive as data events, and version the URL rather than editing objects in place: a new render means a new parameterised URL, and the old one ages out naturally. The one discipline worth enforcing is honest response handling, so a fallback flagged by the provider is stored as the fallback it is, not cached as truth.

Documents are the special case

Anything a customer keeps, contracts, policy schedules, invoices, wants its image frozen at document time, in your archive, unlinked from live catalogues. That copy is deliberately never invalidated; it is the record of what was shown. Licences written for this pattern say so explicitly, and the archive requirement belongs in your evaluation checklist, not discovered during a compliance review.

Cache like an owner, resolve like a subscriber, archive like a registrar.

Cost follows the same arithmetic: the pricing guide shows how cached integrations bend the bill, and the benchmark guide shows how to measure what the layers deliver.

Sizing the win before you build

One afternoon of log analysis predicts the whole project: count image requests per unique vehicle and view for a week. Ratios above ten mean the middle layer pays for itself immediately; ratios near one mean your traffic is long tail and the browser layer plus provider CDN already carry it. Most consumer facing platforms find ratios in the hundreds, which is why this page exists.

Want these images for your inventory?

Tell us which vehicles you list and we will send back real examples from your own stock.

Robin Ashford
Written by
Robin Ashford
Head of Content

Robin writes about the place where cars meet software: imagery, vehicle data and the systems that sell vehicles online. A decade across marketplaces, leasing platforms and dealer tools taught her which problems are real, and the writing here sticks to those.

Found this useful?

Add as a preferred source on Google