Short answer: The first request for a new image variant is usually a cache miss. The service validates the request, locates or fetches the source, decodes it, applies transformations, encodes the result, stores the derivative, and returns it. Later requests can often skip most of that work by using a cached derivative at the edge.
That lifecycle explains why the first response can be slower than the next hundred. It also gives an engineering team a useful map for debugging. A delay before any bytes arrive is not automatically a CDN problem. It may be source retrieval, a transformation queue, an expensive encode, or a signature check.
The request becomes a transformation contract
An image URL is more than a file location. Its path and query parameters can describe the source, dimensions, crop mode, quality, format, and other operations. The API first parses those instructions into a normalized transformation. It should reject unsupported values before spending resources on an origin fetch.
This is why a stable transformation URL contract matters. Two URLs that mean the same thing should not accidentally produce two cache entries. A width of 800, for example, should not be represented by several aliases unless the platform deliberately canonicalizes them.
Managed services expose this contract in different syntax. The underlying stages are similar. Cloudinary documents how URL components select delivery type and transformations in its image transformation guide. Cloudflare likewise describes URL-based image transformations and the options evaluated before delivery in its transformation documentation.
Where does the source image come from?
There are two common source paths. In a managed-asset workflow, the original has already been uploaded and indexed by an asset identifier. In an origin-pull workflow, the service fetches a remote URL when a derivative is requested. Both models need a clear source-of-truth policy.
For managed assets, the service can usually find metadata without contacting an external origin. For origin pull, DNS, TLS, authentication, redirects, and origin response time become part of the cold request. A private or unreliable origin can dominate total latency even when the image processor is fast.
Teams should record whether source retrieval happened, how long it took, and which origin was used. That evidence separates a slow origin from slow processing. It also helps detect unexpected remote fetches, which belong in the site’s security model as well as its performance model.
Decode, transform, and encode
Once the original is available, the processor decodes it into pixels. It then applies the requested crop, resize, rotation, color, overlay, or sharpening operations in a defined order. Finally, it encodes the result into JPEG, WebP, AVIF, PNG, or another supported output.
These steps do not have equal cost. A simple downscale is different from a large animated input, a complex overlay chain, or a modern format encode. Automatic quality and automatic format can improve delivery, but they make testing more important because the exact result depends on content and request capabilities. The separate guide to automatic image quality explains how to set measurable guardrails.
The processor should enforce input size, output dimensions, frame count, and operation limits. Without bounds, one surprising request can consume disproportionate CPU or memory. A production policy should decide which transformations are public, which require signing, and which are unavailable.
Why is the second request faster?
After a successful transformation, the service can store the derivative under a cache identity derived from the source version and normalized transformation. The response may also be cached at one or more CDN edges. A later request with the same identity can return the stored bytes without decoding and encoding again.
That shortcut only works when cache identity is deterministic. Source version changes, query ordering, differing headers, or slightly different widths can all create another miss. Our image CDN comparison explains how transformation and edge delivery responsibilities fit together.
HTTP caching still applies. The semantics of freshness, validation, and stored responses are standardized in RFC 9111. Your image platform adds a derivative-generation layer, but browsers and shared caches still act on response headers.
How should you test the cold path?
Start with a new source version or a transformation that has never been requested. Record DNS, connection time, time to first byte, total duration, response headers, and the final content length. Then repeat the exact URL from the same region and from a second region.
Avoid adding arbitrary cache-busting parameters to production URLs. They can test the wrong thing by creating identities your real application never uses. Use a controlled test asset and a legitimate variant instead.
Compare four cases: warm derivative and warm edge, warm derivative and cold edge, cold derivative with a local source, and cold derivative with a remote source. Not every service exposes a header that distinguishes them, so correlate client timing with server logs where possible.
The first request is not merely an outlier to ignore. It is the moment when your source access, transformation policy, resource limits, cache key, and observability all meet. Design that path deliberately, then let caching make the common path fast.
Leave a Reply