Tag: Delivery

The DAM selection was thorough. Governance, metadata, workflow, integrations, all properly evaluated. Delivery was out of scope because the web team has a CDN.

Eighteen months later the web team has built an image service. It resizes, converts formats, caches, and has a queue of bugs about invalidation. It is now a system nobody planned, nobody owns, and nobody documented, sitting between the DAM and every page.

Short answer: if the DAM cannot deliver a correctly sized, correctly formatted image directly to a browser, somebody in your organisation will build the thing that does. That thing is a second system with its own storage, its own cache, and its own staleness bugs, and it is usually more expensive than the delivery capability you declined to evaluate. Put delivery in the selection criteria.

What “delivery” has to cover

Five capabilities. If the platform does not have them, you are building them.

Resize on request. Any dimension, from a URL, without pre-generating variants. Not a fixed set of preset sizes chosen at configuration time, because the sizes you need change with every design refresh.

Automatic format selection. Serve AVIF to browsers that support it, WebP to those that support that, JPEG to the rest, from one URL. AVIF support is broad enough now that this is a substantial and immediate payload reduction, and WebP covers essentially everything else. The MDN image format guide is the reference for what each format is actually good at.

Automatic quality. Compression tuned per image rather than a global setting. A flat quality number is always wrong somewhere: too aggressive on a gradient, too generous on a flat graphic. Content-aware quality selection removes an entire category of manual tuning.

Content-aware cropping. A 1:1 crop of a wide product shot should keep the product, not the geometric centre. Doing this by rule produces bad crops at volume; doing it by hand does not scale. Cloudinary bundles these three under automatic format, quality and gravity, with the cropping mechanics in resizing and cropping.

Edge caching with sane invalidation. Derivatives cached close to users, and a versioned URL scheme so replacing a master produces a new address rather than requiring a purge across a content delivery network.

Why this is a business number, not an engineering preference

Image weight is usually the largest single contributor to Largest Contentful Paint on a content or commerce page, and LCP is the metric that most directly tracks perceived load speed.

Two consequences that belong in the business case rather than the technical appendix:

Bandwidth cost. You are paying to serve every byte. Get your current monthly image bytes from your CDN, model the reduction from automatic format and quality, and price it at your existing rate. This is a real number from an existing invoice, which puts it in the most credible benefit category in the business case.

Conversion. Page speed affects conversion. State the mechanism, do not put a percentage in the case unless you can run the experiment yourself. Borrowed conversion statistics are the fastest way to lose a reviewer’s trust, and the effect is real enough that you do not need to inflate it.

Responsive is the part that breaks stored variants

This is the argument that settles the derived-versus-stored question on technical grounds rather than economic ones.

A modern responsive page does not know what size image it needs until the browser knows its own viewport, its device pixel ratio, and the layout after CSS has run. The correct width might be 412 pixels, or 824, or 1236. Multiply that by every breakpoint, every density and every art-directed crop and the set of required derivatives is combinatorially large and not knowable in advance.

Stored variants cannot serve that. You end up picking six sizes, serving the nearest larger one, and shipping between twenty and sixty percent more bytes than necessary on most devices.

Derived delivery can, because the size is a parameter and the result is cached on first request. Responsive image delivery covers the mechanics along with the srcset and sizes generation. The important property is that the first request for an uncommon width is slightly slower and every subsequent one is a cache hit, so real traffic converges on cached almost immediately.

What about the CDN we already have?

Reasonable question, and the answer depends on which of two things your CDN does.

A plain CDN caches and serves bytes. It does not resize, convert format, or crop. Put one in front of a DAM that only serves originals and you have fast delivery of oversized images, which is a smaller improvement than it sounds.

An image CDN transforms on the way through. Cloudflare Images, imgix and ImageKit all do this well, and they are legitimate answers if your DAM genuinely cannot deliver.

The trade-off is worth stating plainly rather than dismissing. A separate image CDN gives you a good transformation layer and a second system to operate, with its own origin configuration, its own cache semantics, and its own answer to the question of what happens when a master is replaced or a licence expires. That last one matters more than it looks: an expiry event in the DAM has to propagate to the image CDN, and that propagation is your problem to build and to test.

Where the DAM and the delivery layer are the same platform, that class of problem does not exist, which is the same argument made from the architecture side in single source of truth is an architecture.

What to test in an evaluation

Half a day, and it separates the field faster than any feature matrix.

1. Upload one large photograph. Request it at five widths, in three formats, with two crop strategies, by editing the URL. Time to first byte on a cold request, and again on a warm one.
2. Compare bytes against what your site currently serves for the same image at the same rendered size. That ratio is your bandwidth saving, measured rather than claimed.
3. Replace the master. Confirm that existing references pick up the new version, that old versioned URLs still resolve, and that nothing required a manual purge.
4. Check the cache headers the platform sets by default. Immutable derivatives should carry a long max-age. If they carry a short one, your cache hit rate will be poor and your costs high.
5. Test a restricted asset. Confirm its delivery URL does not resolve without authorisation, using the mechanism in access control on delivery. Public-by-default delivery is a common misconfiguration and it belongs in the security review described in access control, SSO and audit trails.

Accessibility travels with delivery

One thing that gets separated from this discussion and should not: alt text is part of correct delivery, not a content afterthought.

If the DAM holds a default description on the asset and the consuming system fetches it alongside the URL, alt text is present by default and only overridden where context demands it. If the DAM holds it and nobody fetches it, every consuming system reinvents it or omits it, and omission is the usual outcome. The WCAG overview covers the requirement, and the field ownership question is settled in who owns which record.

Ask in every demo whether the delivery API returns the descriptive metadata alongside the asset. Surprisingly often the answer is no, and that single gap is why so many sites have empty alt attributes on images that were properly described upstream.

The one-line version

If the answer to “how does an image get from the DAM onto a page at the right size and format” is “the web team handles that”, you have not finished the evaluation. You have deferred a system.

The API characteristics that make this work are in headless DAM, the patterns for wiring it up are in integration patterns for an enterprise DAM, and if delivery turns out to be your dominant requirement, alternatives to a traditional enterprise DAM is the more useful starting point than a classic DAM shortlist.