AEM Responsive Design & Image Delivery

Responsive AEM development has two related problems that are easy to mix together.

The first is layout. A page has to rearrange itself when the available viewport changes. A three-column section may become one column. A component may occupy twelve grid columns on mobile but only six on desktop.

The second is asset delivery. Even if the layout becomes smaller, the browser should not have to download a 3000-pixel image just to render it inside a 400-pixel container.

These problems need different solutions.

CSS and AEM's responsive layout features control how components occupy the page. The Image Component and the selected image-delivery service control which image resource reaches the browser.

A responsive page is not complete until both are working.

Start With the Browser, Not With Device Names

It is tempting to design an AEM implementation around labels such as desktop, tablet, and mobile.

Those labels are useful while discussing layouts, but the browser ultimately works with available space.

A component may appear inside a full-width hero, a six-column container, a card grid, or a nested container. Two users with the same physical device can therefore need different rendered image sizes depending on the component's position.

A better rule is to design around component/container width and meaningful breakpoints rather than around a list of device models.

Responsive Layout in AEM

AEM's responsive Page Editor uses the Layout Container and responsive grid.

The Layout Container provides a grid-paragraph system in which authors can position and resize components against configured breakpoints. Layout Mode and the emulator make those responsive decisions available during authoring.

A page can therefore keep the same content structure while its layout changes across viewport ranges.

For example:

• on a large viewport, an image and text sit side by side;
• on a smaller viewport, both occupy the full row;
• at a configured breakpoint, an optional supporting component can be hidden.

This is different from maintaining separate mobile and desktop pages.

The content stays the same. The layout adapts.

Breakpoints Have Two Sides

In AEM, responsive breakpoints are not only CSS media queries.

The frontend grid CSS defines the browser behavior, while the Page Editor also needs corresponding breakpoint configuration so authors work against the same layout model.

Adobe's current responsive-breakpoint guidance maps CSS breakpoint widths to cq:responsive/breakpoints in the template structure.

That gives us a useful implementation rule:

The Page Editor breakpoint model and the published CSS must describe the same layout system.

If frontend CSS changes a breakpoint but the template configuration does not, authors can design against one viewport model while the published page behaves according to another.

Adobe's current Layout Container guidance also recommends keeping the breakpoint model small rather than creating many device-specific ranges. The exact breakpoints should still come from the site's design system.

Keep the Grid as Flat as the Design Allows

Nested Layout Containers can solve legitimate design problems, especially when a section needs independent column control.

But nesting should not become the default way to build every page.

Deep grid nesting makes it harder to reason about:

• available width,
• authoring behavior,
• component reflow,
• spacing,
• responsive CSS,
• image-size requirements.

Before adding another Layout Container, check whether the requirement is actually component layout that belongs inside the component's frontend implementation.

Responsive Layout Does Not Automatically Mean Responsive Images

Consider a hero image stored in DAM:

hero.jpg
4000 × 2200

On desktop, the component may render around 1600 pixels wide. On mobile, it may render around 390 pixels wide.

CSS can make the image visually responsive:

.cmp-image img {
    width: 100%;
    height: auto;
}

But CSS alone does not reduce the bytes already downloaded.

If the browser still requests the original 4000-pixel asset, the layout is responsive while the delivery is wasteful.

That distinction matters for page weight and Core Web Vitals.

The Core Image Component

For standard AEM Sites implementations, the Core Image Component should usually be the starting point rather than building image delivery from scratch.

Adobe documents responsive image support, lazy loading, DAM asset integration, accessibility-related behavior, and integration with supported delivery options.

The delivery path can differ by project:

• Adaptive Image Servlet,
• Web-Optimized Image Delivery in AEM as a Cloud Service,
• Dynamic Media when the project uses Dynamic Media capabilities.

These options overlap in some goals, but they are not different names for the same mechanism.

Browser-Native Responsive Selection

Current Core Image Component behavior uses normal browser responsive-image capabilities rather than requiring application JavaScript to make every responsive selection.

Conceptually, responsive markup looks like this:

<img
    src="..."
    srcset="
        image-640.jpg 640w,
        image-1024.jpg 1024w,
        image-1600.jpg 1600w"
    sizes="..."
    alt="..."
>

This is an illustrative browser example, not markup to copy over the Core Component implementation.

The important point is that the browser participates in choosing a candidate based on the responsive-image information it receives.

A browser may also keep a larger image it already downloaded instead of fetching a smaller candidate after a viewport resize. That is normal browser behavior.

Do not validate responsive delivery only by dragging the browser window smaller and expecting a new network request every time.

Image Widths Are a Policy Decision

For delivery paths that expose configured responsive widths, the available widths should come from real component layouts.

A project might need candidates around widths such as 480, 768, 1024, 1440, and 1920 pixels, but that list is only an example.

Too few candidates can make browsers download images much larger than necessary.

Too many arbitrary candidates create unnecessary variants and can weaken cache reuse.

The design system should define a practical width strategy. Individual authors should not have to calculate rendition widths every time they place an image.

Adaptive Image Servlet

The Adaptive Image Servlet is the traditional Core Image Component delivery path.

It serves an image for the requested component width and can work with DAM renditions rather than requiring every request to map directly to the original asset.

The useful architectural point is that the Image Component policy, DAM processing, and browser request all participate in the result.

Application code should not depend on a specific internal rendition name or manually reconstruct Adaptive Image Servlet URLs from observed output.

If a custom component needs Core Image behavior, prefer supported Core Component extension/proxy patterns and APIs over string-building internal delivery URLs.

Original, Rendition, and Delivered Variant Are Different

These terms are often mixed together.

Original

The source asset uploaded to DAM.

For example:

/content/dam/site/products/shoe.jpg

DAM Rendition

A derived representation associated with that asset. Asset processing can create renditions for different purposes.

Delivered Variant

The resource the browser actually receives.

That resource may come through the Adaptive Image Servlet, Web-Optimized Image Delivery, Dynamic Media, or another project-defined delivery boundary.

The browser does not need to know how the repository stores the source asset. It needs an efficiently delivered resource suitable for the rendered experience.

Web-Optimized Image Delivery

AEM as a Cloud Service provides Web-Optimized Image Delivery for the Core Image Component.

Adobe currently documents this as a policy option that delivers DAM image assets in WebP and reports an average image download-size reduction of roughly 25 percent.

The percentage should not be treated as a guarantee for every asset.

The architectural point is more useful: image optimization can move from application-instance image handling toward an optimized cloud delivery service.

For AEM as a Cloud Service projects using standard DAM images, this option should be evaluated before building custom image transformation code.

Dynamic Media Is a Different Delivery Capability

Dynamic Media goes beyond standard responsive resizing.

Depending on the implementation, it can provide capabilities such as:

• image presets,
• URL-driven transformations,
• Smart Crop,
• Dynamic Media CDN delivery,
• Smart Imaging.

Do not describe Dynamic Media as simply another DAM rendition.

The asset may originate in the AEM asset ecosystem, but the runtime delivery architecture and transformation capabilities are different.

Smart Crop Solves a Different Problem From Responsive Width

Suppose a source image shows a person standing on the right side of a wide landscape photograph.

Reducing the image width for mobile preserves the same composition. It may make the subject too small or place it poorly inside a narrow component.

The problem is no longer just file size. It is composition.

That is an art-direction problem.

Dynamic Media Smart Crop can provide crop variants intended for different display contexts while preserving an important region of the image.

This is different from srcset.

Responsive width selection helps choose an appropriately sized resource. Art direction changes what portion or composition of the source is presented.

Do not expect normal responsive-width selection to solve art direction automatically.

Smart Imaging and Modern Formats

Dynamic Media Smart Imaging optimizes delivery according to browser capabilities and Dynamic Media configuration.

Adobe's current documentation includes AVIF and WebP in its format-conversion behavior and requires the out-of-the-box Dynamic Media CDN for Smart Imaging.

This means application code should avoid unnecessary assumptions such as:

Every DAM JPEG must reach the browser as JPEG.

The source format and delivered format can differ.

Adobe also recommends allowing Smart Imaging to negotiate the efficient format instead of hard-coding WebP or AVIF into every URL unless a use case specifically requires a fixed format.

Web-Optimized Delivery and Dynamic Media Are Not the Same

Both can improve image delivery, so they are sometimes discussed as though one is simply the newer name for the other.

They solve overlapping but different requirements.

For a standard AEM as a Cloud Service Sites implementation, evaluate Web-Optimized Image Delivery when the main requirement is efficient delivery of ordinary DAM images.

Evaluate Dynamic Media when the project needs capabilities such as Smart Crop, image presets, dynamic transformations, or the wider Dynamic Media delivery model.

The choice should come from requirements and platform architecture.

Lazy Loading

Lazy loading can reduce initial page work by deferring images that are not immediately needed.

The Core Image Component supports lazy loading, but "lazy load every image" is not a performance strategy.

The image responsible for Largest Contentful Paint is often visible in the initial viewport. Delaying it can hurt LCP rather than improve it.

A practical approach is to prioritize important above-the-fold imagery, defer lower-page images, and test the actual page rather than applying one loading rule to every image component.

Width Is Only Part of Image Performance

A responsive image implementation can still be slow.

Important factors include:

• source dimensions,
• delivered dimensions,
• compression,
• delivered format,
• number of images,
• loading priority,
• cacheability,
• CDN hit rate,
• layout stability.

A correctly sized image does not compensate for ten heavy images loaded before the user needs them.

Likewise, a modern format does not fix poor layout or loading decisions.

Authors Should Choose Content, Not Delivery Mechanics

A healthy authoring model lets authors decide things such as:

• which image belongs in the component,
• the required alternative text,
• whether a deliberate crop/art direction is needed,
• the content-specific presentation.

The implementation should decide things such as:

• supported responsive widths,
• delivery service,
• caching,
• responsive markup,
• loading behavior,
• layout breakpoints.

When authors must routinely upload image-mobile.jpg, image-tablet.jpg, and image-desktop.jpg for normal responsive behavior, check whether delivery responsibility has leaked into content authoring.

Separate crops can be valid when the design genuinely requires art direction. They should not be the default workaround for missing responsive delivery.

Responsive Images and Caching

Responsive variants become more useful at scale when requests can be reused through the appropriate CDN/cache layer.

That is another reason to avoid arbitrary width values from every component.

If the implementation produces widths such as 613, 641, 677, and 719 pixels without a design reason, the site creates more delivery variants with less opportunity for reuse.

A controlled set of meaningful widths can provide a better balance between transferred bytes and cache reuse.

Measure that balance against real layouts and traffic.

Debug From the Requested URL Backward

When an image looks wrong, several layers may be involved:

• browser cache,
• CDN,
• Dispatcher for relevant delivery paths,
• AEM image processing,
• Dynamic Media delivery,
• the DAM source asset.

Start with the URL the browser actually requested.

Then identify which delivery path owns that URL.

That immediately narrows the investigation.

A correct DAM thumbnail does not prove the public browser received the correct image.

Production Problem — Mobile Downloads a Large Image

Open the browser network panel and inspect the actual request.

Check:

1. Does the markup expose responsive candidates?
2. Which candidate did the browser choose?
3. What is the rendered component width?
4. Are the configured widths sensible?
5. Is the browser reusing a larger cached candidate?
6. Which delivery path produced the response?

Do not begin by creating another DAM rendition.

First prove that rendition availability is the problem.

Production Problem — Image Looks Blurry on Desktop

Inspect:

• rendered CSS width,
• device pixel ratio,
• available candidate widths,
• source asset resolution,
• selected image request.

The largest configured candidate may simply be too small for the rendered context.

The fix may belong in component policy rather than component Java code.

But increasing every candidate width without measurement can increase page weight elsewhere.

Production Problem — Layout Works in Author but Breaks on Publish

Separate authoring configuration from frontend delivery.

Check whether:

• the same responsive-grid CSS is deployed,
• required Clientlib categories load on Publish,
• breakpoint CSS agrees with template breakpoint configuration,
• cached CSS is stale,
• Dispatcher/CDN rules block a required resource,
• custom CSS overrides the responsive grid.

The emulator helps authors work with responsive layouts. The public browser on Publish remains the final runtime to verify.

Production Problem — Correct DAM Asset, Old Browser Image

Follow the requested resource rather than repeatedly replacing the asset.

Check the component asset reference, public image URL, cache behavior, and the state of whichever delivery service owns that URL.

For Dynamic Media, include Dynamic Media publication/delivery state in the investigation.

The repository and the public delivery layer are related, but they are not the same thing.

Production Problem — Smart Crop Looks Wrong

If the project uses Dynamic Media Smart Crop, verify the crop and delivery behavior before hiding the problem with CSS.

Check:

• source composition,
• Smart Crop definitions,
• crop used by the component,
• rendered aspect ratio,
• Dynamic Media request/modifiers,
• whether the design requires a deliberately different composition.

object-fit: cover can fill a box. It cannot guarantee that the important subject remains visible.

Headless AEM Changes the Ownership Boundary

In a traditional Sites implementation, the Core Image Component can own much of the markup and delivery behavior.

In a headless application, the frontend may own <picture>, <img>, responsive candidates, loading behavior, and layout.

That does not remove the need for an image-delivery architecture.

The project still needs to decide:

• what image reference the API exposes,
• which service owns transformations,
• which widths/presets are supported,
• how crops are represented,
• who constructs delivery URLs,
• how images are cached,
• who owns accessibility metadata.

Headless moves responsibility. It does not make image optimization automatic.

Keep Image-Delivery Logic Behind a Boundary

A long-term problem appears when image URL construction spreads across HTL, Sling Models, JavaScript, Content Fragment consumers, utility classes, and mobile applications.

A delivery-service change then becomes a migration across the entire codebase.

For Sites components, reuse supported Core Component behavior where it fits.

For headless consumers, define a stable image model or URL-generation boundary instead of teaching every component the internals of DAM or Dynamic Media URLs.

Choosing the Delivery Strategy

There is no single image path for every AEM implementation.

For a normal Sites implementation using Core Components, start with the Core Image Component and the platform-supported delivery options.

For AEM as a Cloud Service, evaluate Web-Optimized Image Delivery when the requirement is efficient standard DAM image delivery.

If the project requires Smart Crop, image presets, dynamic transformations, or broader Dynamic Media capabilities, evaluate Dynamic Media as part of the asset architecture.

If the frontend is headless, decide explicitly which responsibilities remain in AEM and which move to the consuming application.

Make the choice at the architecture level instead of solving image delivery differently in every component.

A Practical Production Review

Before calling responsive image delivery complete, test representative pages at realistic viewport sizes.

For important images, record:

• rendered width,
• selected request URL,
• transferred size,
• delivered format,
• loading behavior,
• cache behavior,
• visual quality.

Trace those observations back to component policy, layout breakpoints, delivery configuration, and the DAM source asset.

Repository configuration can look correct while browser behavior is still poor.

Summary

Responsive AEM implementation has two responsibilities.

The layout must adapt to available space.

The image-delivery layer must avoid sending unnecessarily expensive assets into that layout.

AEM's Layout Container and responsive grid provide the authoring and layout model. The Core Image Component provides a supported starting point for responsive image behavior.

Depending on the platform and requirements, delivery may use the Adaptive Image Servlet, Web-Optimized Image Delivery, or Dynamic Media capabilities.

The key is not to mix their responsibilities.

A CSS breakpoint does not select a DAM rendition.

A DAM rendition does not define page layout.

Responsive width selection does not solve art direction.

Smart Crop does not replace responsive layout.

Lazy loading does not make every image fast.

When those boundaries are clear, responsive design becomes easier to author, optimize, and troubleshoot.

What's Next

The roadmap maps rw-12 — Optimized Image Delivery with DAM Rendition Fallback to this chapter.

That companion covers an Asset Delivery API implementation with a graceful fallback to a static DAM rendition when the asset is unbound. We will keep the companion limited to the real project facts already recorded for that scenario.

After the companion:

Chapter 35 — Component Frontend Architecture