Key takeaways
Amplience Dynamic Media stores one master asset and generates every variant on demand through a URL parameter or API call. Nothing is pre-rendered.
Adding a new channel, device size, or locale is a URL template change, not a new production run.
Adding fmt=auto to your image URL tells the CDN to detect the browser and serve the best available format automatically, from AVIF to WebP to JPEG. You don’t need to maintain complex picture tags by hand.
Dynamic Media is a transformation and delivery layer, not a DAM. A DAM stores assets. Dynamic Media transforms and delivers them. They solve different problems.
Dynamic Media fits a composable or headless stack without forcing a rebuild. It works alongside your existing CDN, CMS, and upstream DAMs.
If media is a top contributor to your page weight, or you’re pre-producing multiple asset variants by hand, Dynamic Media is worth a serious look.
In the first article we made the business case: media is the heaviest thing on most retail pages, and managing it the old way is slow, manual, and expensive. This article is the practical companion. Here’s how Dynamic Media actually works, and how to tell when it’s the right tool.
How does Amplience Dynamic Media work?
The model is simple, and the simplicity is the point.
Upload one master. Store a single, high quality master asset in the DAM.
Request a transformation. Ask for the variant you need through a URL parameter or the API. Size, crop, format, quality, effects.
Render on the fly. Dynamic Media generates that exact variant in real time. No pre-production, no batch exports.
Cache and serve. The output is cached and delivered from a global edge network, close to the user.
One master, many outputs. No file sprawl, no duplicate assets to keep in sync, one source of truth.
Built for developers
Dynamic Media is API-first and URL-driven, so it naturally fits into a composable or headless architecture without forcing a rebuild around it.
Transform by URL. Hundreds of transformations are available as URL parameters: resize, scale, rotate, crop, sharpen, adjust color, and more. A change is an edit to a string, not a new asset.
Transformation templates. Rather than hardcoding long parameter strings in your markup, define reusable templates. Front-end code stays clean, and brand rules stay centralized.
Smart images. Add fmt=auto and the CDN detects browser support and serves the best format available, from AVIF to WebP to JPEG. You stop maintaining complex <picture> tags by hand and let the platform keep pace with format standards.
Framework loaders. Custom loaders map Amplience parameters cleanly into frameworks like Next.js, Nuxt, and Astro.
Structured content and media. Media is referenced through structured content, so the front end does not break when content changes, and content teams can work without raising a developer ticket for every resize.
How does Dynamic Media handle performance and caching?
Speed and control are built into the delivery path, not bolted on.
Multi-tier caching. A three-layer architecture spans the browser cache, a global edge CDN of points of presence, and a mid-tier read-through cache in front of the image processing origin. Most apps should use the Cached API for delivery and reserve the Fresh API for low-volume cases like static site generation.
Automatic optimization. fmt=auto, next-gen formats through Accelerated Media, and progressive loading reduce page weight and improve perceived speed, especially on mobile.
Consistency from a single master. Because every variant derives from one source, brand and quality stay consistent across every channel by default.
Cache purging. When an asset changes, targeted purging invalidates it across the CDN so updates propagate cleanly.
A quick worked example. A single master can serve a sharp desktop hero, a cropped mobile version that keeps the subject in frame, and a lightweight thumbnail, all from the same source, all through different URL parameters. Nothing is pre-produced.
When should you use Dynamic Media?
Dynamic Media earns its place fastest in these situations:
You are re-platforming. Moving to composable or headless commerce is the natural moment to take media off the old monolith and onto an API-first service.
You have a page-speed or Core Web Vitals mandate. Media is usually the largest single contributor to page weight, so it’s the highest-leverage place to start.
You are expanding channels, regions, or devices. When every new surface used to mean another round of asset production, on-the-fly transformation removes the multiplier.
You have a large or fast-growing catalog. Heavy, frequently changing media is exactly where pre-rendering breaks down.
You are migrating off pre-rendered variants or a legacy media server. Teams replacing tools like Adobe Scene7 move to a single master plus transformation templates, as many of our customers did across different brands and multiple locales.
It also fits specialized media needs. JD Sports used video transcoding to cut the number of videos produced for in-store signage, generating the right formats and aspect ratios on demand. Mars used Dynamic Media for product customization and visualization, including monogramming.
Where does Dynamic Media fit in your tech stack?
Dynamic Media handles transformation and delivery. It works best alongside the rest of the Amplience platform: Content Hub (DAM) to manage and master assets, and Dynamic Content (CMS) to build the experiences. It complements your existing CDN and front end rather than replacing your whole architecture, and it integrates with upstream DAMs. Customers like BoConcept master assets in tools such as CELUM and Aprimo, then push to Amplience for dynamic delivery.
It helps to be precise about the difference between a DAM and a delivery layer, because they’re often confused. A DAM stores and organizes assets: versioning, metadata, tagging, governance. Put an image in, get the same image out. That’s necessary, but it doesn’t transform an image per device, negotiate the lightest modern format, or serve it from a global edge. Those jobs belong to a delivery layer.
This is why a DAM on its own does not move your page speed or Core Web Vitals numbers. Without a delivery layer, teams either keep pre-producing variants by hand or bolt a separate image CDN onto the stack. That leaves you running three systems, a CMS, a DAM, and an image CDN, with transformation logic split from where your assets and content live. In Amplience, the DAM and the delivery layer are one platform, so assets, metadata, transformations, and delivery sit together.
To be clear about scope: Dynamic Media is a media transformation and delivery service. It’s not a creative editing suite or a replacement for your design tools. Its job is to take finished masters and deliver the right version, fast, everywhere.
Is Dynamic Media right for you? A quick checklist
Is media a top contributor to your page weight and load times?
Do teams pre-produce multiple sizes or crops of the same asset by hand?
Are you adding channels, locales, or device types faster than you can produce assets?
Do content changes routinely wait on developers?
Are you on, or moving toward, a composable or headless architecture?
Are you trying to retire a legacy media server or a library of pre-rendered files?
If you answered yes to two or more, Dynamic Media is worth a serious look.
Build once. Deliver everywhere.
Build it once, deliver it everywhere. One master, an API call, and a global edge network do the work that used to take a production pipeline. Less manual effort, measurable speed, consistent media on every screen.
Ready to see it against your own stack? Book a demo.