Media Assets

In every website, media assets like images or videos play an important role to transport information or provide an engaging experience to visitors.

Dedicated Delivery Infrastructure (Media Bus)

As image and video delivery is crucial to the performance a website, AEM has a built-in facility named Media Bus, that makes sure that the media delivery is fast (same-origin), flexible (dynamic image rendering), reliable (built on a dual stack architecture), immutable (cache-optimized) and simple to setup as part of the origin (no special CDN rules, single AEM origin).

As long as they adhere to the documented limits, the Media Bus facility is used for images and videos copy/pasted into a document, or uploaded as separate files. To avoid duplication of media binaries, the Media Bus is using Content Addressable Storage internally, meaning that every asset is only stored once with a unique hash, visible in the URL following the media_ prefix. This system also allows AEM to cache assets permanently.

Images

Images that are copy/pasted into a document are deduplicated and added to the Media Bus when the document is previewed. Images that are uploaded as separate files are also added to the Media Bus and a 301 redirect will be added for the original filename of the asset. Original image sizes (for correct aspect ratio) are provided in the <img> tag via height and width attributes to provide the proper aspect ratio to the browser. Lazy loading is enabled by default for performance reasons.

Dynamic Image Manipulation

The query parameters height, width, format and quality are supported. By default, an image is rendered as a <picture> tag with <source> and <img> children, providing a 750px version for mobile and a 2000px version for desktop in both webp and original png or jpeg renditions as fallback.

Filenames

It may be useful to add filenames to the files that are different from the hash (e.g. a simplified version of the alt text) to provide a better "Save as…" experience in the browser. There are some sources that claim there is SEO value as well in providing named image resources.

To create your custom image source, you can just modify the URL to insert the filename between the media_<hash> and file extension: ./media_<hash>/<filename>.<extension>
For example: https://www.aem.live/media_1645e7a92e9f8448d45e8b999afa71315cc52690b/hero-collage.png?width=2000&format=webply&optimize=medium, will use hero-collage.png as a filename when using the browser's save dialog.

alt Text

alt texts should only be supplied if an image is informative or functional. For decorative images a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users from the adjacent text.

Equally important, the context of an informative image matters, meaning that the same image used in multiple contexts likely needs different alt texts for them to be useful, so it is more sensible to store the alt text with the reference as opposed to storing the alt text with the asset.

Centralized Asset Management and Delivery (Digital Asset Management)

In certain situations it may be desirable to have a dedicated centralized management infrastructure, e.g. a Digital Asset Management System (DAM) like AEM Assets, to enforce curation and reuse policies and processes, as well as advanced image manipulation.

There are generally two ways to integrate a centralized DAM, which are differing in a couple of characteristics.

Approach A: Built-in Media Bus Delivery

When assets are managed centrally, a browsing interface (e.g. asset picker) is provided that allows the author of a page to copy a reference (URL to the DAM) or the actual image (pixels) into their document as an image. The actual implementation on the image being referenced by URL or a copy being created when the image is inserted into the document largely depends on the setup of the content source.
Word and Google Docs only support images that are contained in the document itself and therefore will create a copy of the image that's selected from the DAM.
Document Authoring offers both, keeping a reference to a URL to the document as well as making a copy of the image. Most Bring your own Markup setups work by reference.

Either upon paste or upon preview, the image is requested from the DAM and is added to the Media Bus, and delivered natively through the same origin, preserving the built-in performance, reliability and simplicity of the CDN setup. Dynamic or advanced image manipulation (e.g. smart crop, auto-tagging, etc.) is limited to the point of ingestion (meaning at paste or preview time).

This approach is applicable in situations where simplicity and performance are key, and advanced image manipulations can be applied as part of the authoring flow. This approach also assumes a connected lifecycle of content (page or fragment) with the images that are in use, and a change of an image in the DAM requires an update of the preview and republishing of the containing pages.

Approach B: Asset Management Delivery

Similar to Approach A, a browsing interface (e.g. asset picker) is provided that allows the author to select the image to use. But instead of inserting it as an image into the document, it is managed as an external link that is directly pointing to the DAM's CDN.
Content sources such as Document Authoring or Universal Editor still may display the image to the author, based on the known URL structure (e.g. hostname or URL prefix) of the links to the DAM, but from a content modeling perspective it is seen as a lin, to make sure that the content structure stays compatible across all supported content sources.

In the browser, the linked URLs to the assets are rewritten from <a> to <picture> and <img> tags, depending on the capabilities of the asset delivery system. This happens very early on in the page decoration process in scripts.js and has no negative performance impact by itself.

To make sure that the delivery performance in production is kept up to par, the CDN setup of the production domain needs to include a special route to the DAM's CDN to make sure that the LCP image can be delivered from the same origin, including cache settings, invalidation (if needed) as well as careful consideration for compression and dynamic image sizes.

This approach is useful for situations where images are dynamically manipulated based on the context of the site visitor, beyond different images sizes, formats and compression, and advanced manipulations provided by the DAM cannot be applied at authoring time. This approach assumes a disconnected lifecycle between images and content, and changes to an asset in the DAM are immediately reflected on the site.

Videos

Short videos can be uploaded as MP4 files to the Media Bus to allow for performance-focused, same-origin delivery of hero videos above the fold. For long-form videos we recommend to use aDAM (like AEM Assets) or a video streaming service (like YouTube or Vimeo).

For the author, the reference to a video is a link in a document (similar to Approach B for centrally managed images). To be able to replace the media without changing the references, it is commonly recommended to use the human-readable redirect URL to the MP4 file as obtained during preview as opposed to the media_<hash> URL.

It is recommended to also include a poster image that can be loaded quickly and can be used as a fallback if the autoplay feature of an ambient video is disabled (e.g. Mobile Safari in "Low Power Mode").

PDF & SVG

PDF and SVG files are both supported, but are delivered as part of the content (not via media bus) which means that they are following the regular preview and publish lifecycle and are not stored in a de-duplicated, content addressed fashion.