For a site holding both editorial images committed to the repository and images uploaded by users, how would you decide between generating image derivatives at build time and generating them at request time through an image CDN?

## Two pipelines, one question Both pipelines end in the same place — correctly sized, modern-format images at the edge. They differ in *when* the encode happens and *who owns the risk*. **Build time:** a step in CI reads each source image, produces every variant you configured, and emits real files. The deployed artifact contains them. Serving is then a solved problem: static files, content-addressed names, long `max-age`, no compute in the request path. **Request time:** one master sits at an origin, and an image CDN produces variants when they are first requested and caches them. ## What build time buys - **No runtime dependency.** The images are files. If your image vendor has an outage, nothing happens to you. - **Deterministic output.** The bytes were produced once, reviewed if you like, and cannot silently change because a provider updated an encoder. - **No metered transformations.** The cost is CI minutes, which you already pay for and can measure. - **Trivial caching.** Content-hashed filenames plus immutable caching is the easiest caching story that exists — no `Vary`, no key normalization, no cold-miss cliff. ## What build time costs - **Build duration scales with images times variants.** Encoding AVIF in particular is slow. A few hundred images across a handful of widths and two formats turns into thousands of encodes, and re-doing them on every CI run is intolerable. This is survivable only with a **persistent cache keyed by source hash plus transform**, so unchanged images are never re-encoded — and that cache becomes something you now operate. - **The variant matrix is fixed at build.** Adding a width or a format means a rebuild and redeploy of the whole set. - **It cannot serve what does not exist yet.** This is the hard boundary. ## What request time buys - **Unbounded and unknown inputs work.** User uploads, images pulled from a CMS after deploy, or a catalogue too large to pre-render are all fine. - **Policy is changeable without a rebuild.** Lowering quality site-wide, or enabling a new format, is a configuration change that takes effect on the next miss. - **You only produce what is actually requested.** A long-tail catalogue where 90% of items are rarely viewed never pays for the variants nobody asked for. ## What request time costs - **Cold-miss latency**, landing on a real visitor, and concentrated exactly where it hurts — new pages, new campaigns, long-tail content. - **Metered spend** on transformations and derivative storage, which turns cache-key discipline into a budget line and abuse into an availability problem. - **A dependency in the critical path.** Provider outage means missing images. - **Lock-in through URL syntax.** Parameter dialects differ per vendor; if templates write them by hand, migration means touching every template. ## The hybrid, and how to split it Most mature sites run both, and the honest split is not "editorial versus product" but **enumerable versus not**: - Anything you can list at build — marketing pages, the design system, blog assets — goes through the build pipeline with a persistent encode cache. - Anything that arrives later — uploads, syndicated content, catalogue images managed outside the repo — goes through the image CDN. On top of that, apply a criticality override. The single largest image on your highest-traffic entry point deserves special treatment whichever pipeline owns it: pre-generate it, or warm its exact derivative URLs after deploy so no visitor pays the miss. ## Keeping the decision reversible Whichever way you go first, you will likely revisit it, so build the exit now: - **One URL helper.** Every image URL in the codebase comes from a single function that takes an image reference and a preset name. Swapping providers, or moving one class of images from one pipeline to the other, becomes one file. - **Named presets, not free-form numbers.** Presets are portable across pipelines and bound the variant set on both sides. - **Stable, versioned source paths** so a changed image is a new URL, which keeps both pipelines honest about cache invalidation. ## How I would present the decision Start from the inputs, not the tooling: are the images enumerable at build, how many are there, and how often do they change? Then price the two failure modes against each other — a slow build that delays every deploy versus a metered runtime dependency with a cold-start cliff. Then decide per class of image rather than for the whole site, and write down the criticality exception for the hero. An interviewer at this level is listening for that structure, and for whether you noticed that "user uploads" alone already forecloses the pure build-time answer.