Every provider claims fast. No number in a vendor deck, ours included, should decide an integration, because image API performance depends on where your users are, what you request and how you cache. What a vendor can honestly give you is architecture and a method. Here are both.
What actually determines speed
- Edge caching: whether the image is served from a CDN node near the user or rendered on demand
- Payload size: format and dimensions. A 1200px WebP is a fraction of a full-size PNG
- Cold vs warm: the first request for an unusual trim-colour-angle combination does more work than the millionth request for a popular one
- Your own caching: an image URL stored in your CDN or bucket costs zero API latency on every subsequent view
Cached delivery from the edge is typically in the tens of milliseconds, essentially network distance. Cold renders take longer, and any honest provider will say so. The performance question is therefore really a cache-hit-ratio question, and your access pattern decides that more than the vendor does.
The four numbers worth measuring
| Metric | What it tells you | How |
|---|---|---|
| TTFB, warm | Edge delivery speed | Repeat requests for the same URL |
| TTFB, cold | Render pipeline speed | First requests for rare combinations |
| p95, not average | What slow users experience | Hundreds of requests, look at the tail |
| Bytes on the wire | What mobile users download | Compare format and width variants |
A benchmark you can run in an afternoon
Take twenty vehicles from your own catalogue, real ones, including unpopular trims. For each, request the angles you would actually display, in the format and size you would actually serve, for example front_left?format=webp&width=1200. Run each URL twice, from the regions your users are in, and record cold and warm timings separately. Repeat at your peak-hour equivalent concurrency.
Two details make or break the honesty of the result. First: measure the tail, not the mean. One slow render hidden in a fast average is exactly what your users will notice. Second: benchmark the payload alongside the latency, because a provider that returns twice the bytes at the same TTFB is slower on every real phone.
Payload discipline
- Request WebP unless you specifically need PNG transparency for print or compositing
- Request the width you render. Sending a 2400px image into a 600px slot is pure waste
- Use the quality parameter deliberately; vehicle cutouts survive compression well
- Cache aggressively on your side: the fastest request is the one you never make
Reading the results honestly
When the numbers come back, resist averaging them into one score. A provider with a fast warm path and a slow cold path suits a marketplace whose top thousand vehicles absorb most traffic, and suits a long-tail insurance quote flow much worse. Match the shape of the latency profile to the shape of your access pattern, because that fit matters more than which vendor wins the headline median.
Our own architecture, meaning request parameters, formats and delivery, is documented on the vehicle image API page and in the API docs. Run the afternoon benchmark against us and against anyone else you are considering; that comparison beats any table we could publish.
