I85PREP
⌘ K
AEM Assets Developer Professional study materials
AEM Assets Developer Professional study resources

Rendition Mismatch After Web-Enabled Image Ingestion

AEM Assets Developer Professional · Put your knowledge to work in context.

All case studies

Rendition Mismatch After Web-Enabled Image Ingestion

A brand team uploads 40,000 product photos (avg 12 MB, sRGB JPEG) through the Assets web UI into /content/dam/brand/products. The upload completes, but downstream the web team reports that thumbnails on the category page are 2.4 MB each and pages are slow. Investigation shows the original renditions are correct, but the 140x100 and 319x319 web renditions are larger than expected and some assets have no web rendition at all. The instance uses the default Dynamic Media or standard image processing workflow configuration. There is a strict 15-minute window before the campaign launch, and re-uploading is not possible.

1. What are the most likely reasons the web renditions are oversized or missing, and how do you confirm each hypothesis without re-uploading?

Read the worked answer

Two distinct failure classes must be separated.

  1. Oversized renditions: The default web rendition dimensions are governed by the workflow's image-preset/ImageHelper step and the DAM Update Asset workflow model. If the original is large and the workflow's resize step is skipped or the preset uses a high quality/compression setting, the output stays large. Confirm by opening one asset's rendition panel, checking the rendition's pixel dimensions and file size, and comparing against the expected 140x100 / 319x319 presets. Also check whether the asset was processed by the default workflow at all (metadata dam:lastProcessed / workflow history).

  2. Missing renditions: Often caused by ingestion that bypasses the DAM Update Asset workflow (e.g., direct JCR writes, package installs, or a custom ingestion path), by mime-type detection failing, or by the workflow being terminated. Confirm by inspecting workflow instances for the batch and looking for failed/aborted DAM Update Asset processes.

Because re-upload is off the table, the fix is to re-run the DAM Update Asset workflow against the affected paths (via the workflow console or a bulk reprocess), not to re-ingest.

2. The launch is in 15 minutes. What is your immediate mitigation and what is the follow-up remediation?

Read the worked answer

Immediate mitigation (minutes):

  • If Dynamic Media is available, switch the category page to Dynamic Media delivery with URL modifiers (e.g., ?wid=140&hei=100) so the browser receives correctly sized images regardless of stored renditions. This is the fastest path and does not require reprocessing.
  • If not, identify the highest-traffic templates and point them at the original or a known-good larger rendition with CSS sizing as a stopgap, accepting larger payloads temporarily.

Follow-up remediation:

  • Bulk re-run DAM Update Asset on /content/dam/brand/products to regenerate missing/oversized web renditions.
  • Audit the workflow model and image presets to ensure resize + appropriate JPEG quality are applied by default.
  • Add a post-ingestion validation check (rendition existence and size thresholds) so future batches fail fast rather than silently.
  • Consider an ingestion path that guarantees workflow execution for bulk loads.