Build time vs runtime

Build-time vs runtime image optimization

Choose where image transformation belongs based on how your media changes and ships.

Choose build time for reviewable assets

Build-time generation fits source-controlled catalogs that change with application releases. Derivatives, responsive candidates, and metadata can be reviewed together, checked in CI, and served by any static host or CDN.

Marketing, documentation, product, and editorial images released with code
Controlled width and format sets shared across frameworks
Teams that want a source-to-derivative diff before deploy
Deployments that should not depend on a request-time transformation service

Choose runtime for dynamic media

Request-time services fit user-generated or rapidly changing media, dynamic crops, remote catalogs, and teams that want managed storage, delivery, editing, or analytics. They can generate device-specific variants without rebuilding the application.

Uploads or remote sources that arrive after the application build
Dynamic focal points, crops, overlays, or signed delivery URLs
Large media libraries managed outside the source repository
Operations teams that prefer a managed transformation and CDN control plane

Use a hybrid deliberately

A project can pre-generate stable application assets while leaving user media to a runtime service. Define ownership by directory or source system so one image is not transformed twice and cache invalidation remains understandable.