Custom Component Bypassing Asset Delivery Best Practices
A developer builds a custom teaser component that renders images by reading jcr:data from the asset's original rendition via a Sling Model and writing it inline as a base64 data URI. The component works in author but production pages are slow and images are blurry on retina screens. The site has Dynamic Media available but the component does not use it. Images are 4000px originals; the design needs 800px and 1600px variants. There are 30 teasers per page.
1. Explain the performance and quality problems caused by this approach.
Read the worked answer
- Base64 inline of originals: each teaser embeds a 4000px original as base64, inflating HTML size by ~33% and blocking HTML parsing; 30 teasers multiply this. No browser caching of separate image requests, no CDN benefit.
- No responsive variants: a single 4000px image is downscaled by CSS, wasting bandwidth and producing blurry results on retina (no 2x source).
- Bypasses Dynamic Media: no smart imaging, format negotiation (WebP/AVIF), or on-the-fly resizing.
- Server cost: reading
jcr:dataand encoding per request is expensive and not cache-friendly.
Confirm by measuring HTML payload size and Lighthouse metrics, and checking whether images have srcset.
2. Rewrite the delivery approach using AEM/Dynamic Media capabilities and show the key markup pattern.
Read the worked answer
Use Dynamic Media (or the core image component) to generate responsive renditions and let the browser pick.
- Configure the component to output an
<img>withsrcsetfor 800w and 1600w (and a 2x for retina), withsizesmatching layout. - Use Dynamic Media URL modifiers for on-the-fly sizing and format, e.g.
?wid=800&fmt=webpand?wid=1600&fmt=webp, or the Smart Imaging endpoint. - Ensure the image is served from the CDN, not inlined.
Example pattern:
<img
src="/is/image/company/asset?wid=800"
srcset="/is/image/company/asset?wid=800 800w,
/is/image/company/asset?wid=1600 1600w"
sizes="(max-width: 768px) 100vw, 50vw"
alt="..." loading="lazy">
This removes base64, enables caching/CDN, and delivers correct resolution per device.
3. What governance step prevents this regression across the codebase?
Read the worked answer
- Code review checklist / lint rule that flags
jcr:datareads and base64 image output in components. - Standardize on the core image component or a shared Dynamic Media image component so teams do not hand-roll delivery.
- Performance budget in CI (page weight, image bytes) to catch regressions before release.
- Document the approved delivery pattern and require exceptions to be justified.