AEM Dynamic Media Bildvorgaben, Smart Imaging und Web-optimierte Bildauslieferung so einsetzen, dass das Hauptbild früh erscheint
Auf 73 Prozent der mobilen Seiten ist das größte sichtbare Element ein Bild (HTTP Archive Web Almanac 2024). Damit entscheidet die Bildauslieferung auf den meisten Seiten über den Largest Contentful Paint. Adobe Experience Manager bietet dafür Dynamic Media, die Bildkomponente der Core Components und in AEM as a Cloud Service eine Web-optimierte Bildauslieferung. Jeder dieser Wege liefert passende Formate und Größen, und jeder lässt sich so einbauen, dass das Hauptbild trotzdem spät kommt.
Im AEM Core Web Vitals Benchmark 2026 liegt bei 19,7 Prozent der AEM-Auftritte mit zu langsamem Hauptinhalt die Antwortzeit des Servers im guten Bereich, die Ursache also im Frontend bei Bildern, Schriften oder Skripten. Bei den übrigen beginnt die Arbeit beim Dispatcher-Cache, weil eine späte Antwort jedes Bild mit verzögert.
1,9 Prozent der geprüften AEM-Auftritte zeigen auf Smartphones das typische Bildmuster: Der erste Inhalt erscheint schnell, der Hauptinhalt verfehlt den Grenzwert. Zwischen beiden liegen bei ihnen im Median 1.643 Millisekunden.
Dynamic Media und Bildvorgaben: eine Masterdatei, Varianten je Adresse
Dynamic Media, früher Scene7, speichert eine Masterdatei und erzeugt Varianten bei der Auslieferung. Breite, Ausschnitt, Schärfung und Qualität stehen als Befehle in der Bildadresse. Wiederkehrende Kombinationen werden als Bildvorgabe (Image Preset) gebündelt, im Modus Dynamic Media Scene7 ohne gesonderte Veröffentlichung (Adobe: Managing image presets). Für die Performance zählen drei Punkte:
- Die Breiten der Vorgaben folgen den Umbruchpunkten des Layouts, nicht der Größe der Masterdatei.
- Angegeben wird nur eine Dimension, damit das Seitenverhältnis erhalten bleibt.
- Die Qualität ist bewusst gesetzt. Bei Dynamic Media with OpenAPI gilt ohne Angabe eine Höchstqualität von 85 (Adobe).
Smart Imaging: Format, Pixeldichte und Bandbreite je Anfrage
Smart Imaging wählt bei jeder Anfrage das effizienteste Format, das der Browser unterstützt, also AVIF oder WebP. Ohne Smart Imaging bleibt es beim angefragten Format, meist JPEG. Voraussetzung ist das von Adobe mitgelieferte CDN (Adobe: Smart Imaging). Zwei weitere Schalter steuern die Größe:
- Pixeldichte: Mit
dpr=onpasst Dynamic Media die Auflösung an hochauflösende Bildschirme an. Den Wert dafür muss die Seite im Browser ermitteln. - Bandbreite: Mit
network=onrichtet sich die Qualität nach der tatsächlichen Verbindung. Der Standard istoff, bei schlechter Verbindung schaltet Smart Imaging die Anpassung an die Pixeldichte ab.
Ein fest eingetragenes Format wie fmt=webp übersteuert die Aushandlung. Solche Adressen stammen häufig aus älteren Komponenten und verhindern AVIF auch dort, wo der Browser es könnte.
Core Components und Web-optimierte Bildauslieferung in AEM as a Cloud Service
Die Bildkomponente der Core Components unterstützt Dynamic-Media-Bilder seit Version 2.13.0, mit Bildvorgaben, Smart Crop und Bildmodifikatoren (Adobe: Image Component). Ohne Dynamic Media bietet AEM as a Cloud Service die Web-optimierte Bildauslieferung: Eine Option in der Richtlinie der Bildkomponente liefert WebP aus, laut Adobe im Schnitt etwa 25 Prozent kleiner, Browser ohne WebP erhalten JPEG oder PNG (Adobe: Web-Optimized Image Delivery). Der Dienst gilt nur für Bilder unter /content/dam, nicht im lokalen SDK, und rechnet höchstens aus einer Rendition von 2.048 Pixeln Breite.
| Weg | Formate und Größen | Voraussetzung | Grenze |
|---|---|---|---|
| Dynamic Media mit Smart Imaging | AVIF oder WebP je Browser, Breite per Vorgabe | Dynamic Media mit Adobe-CDN | fest eingetragenes Format übersteuert die Aushandlung |
| Dynamic Media with OpenAPI | Breite und Qualität per Parameter | AEM as a Cloud Service | erweiterte Modifikatoren laut Adobe noch nicht verfügbar |
| Web-optimierte Bildauslieferung | WebP, sonst JPEG oder PNG, Breiten aus der Richtlinie | AEM as a Cloud Service, Bilder im DAM | Basis höchstens 2.048 Pixel breit |
| Edge Delivery Services | Größen automatisch optimiert | Edge Delivery Services | LCP-Kandidat ist das erste Bild der Seite |
Fehlerbilder in AEM-Projekten: verzögertes LCP-Bild, fehlende Priorität und fehlende Abmessungen
Gute Formate helfen wenig, wenn der Browser das Hauptbild spät anfordert. Fünf Muster kehren wieder:
- LCP-Bild verzögert geladen: 16 Prozent der mobilen Seiten laden ihr LCP-Bild mit Lazy Loading (Web Almanac 2024). Die Bildkomponente bietet dafür die Richtlinien-Option Disable lazy loading; sinnvoll ist eine eigene Richtlinie für Bühne und Aufmacher.
- Fehlende Priorität:
fetchpriority="high"am LCP-Bild verbesserte in einem Beispiel von web.dev den LCP von 2,6 auf 1,9 Sekunden (web.dev). Das Attribut gehört an genau ein Bild. - Fehlende Abmessungen: Ohne Breite und Höhe im Markup springt das Layout beim Laden und erhöht den Cumulative Layout Shift. Version 3 der Bildkomponente setzt beides.
- Zu große Varianten: Eine Vorgabe mit fester Breite oder ein fehlendes
srcsetschickt Smartphones Bilder in Desktopgröße. - Bild per JavaScript: Setzt ein Skript oder Viewer die Bildadresse erst nach dem Laden, erfährt der Browser spät vom Bild. Liefert Dynamic Media von einem eigenen Host, kommt der Verbindungsaufbau hinzu.
Edge Delivery Services: erstes Bild in der Eager-Phase
Bei AEM Edge Delivery Services lädt die erste Ladephase die erste Section mit Vorrang für deren erstes Bild als LCP-Kandidaten. Hat eine Bühne getrennte Bilder für Mobil und Desktop, gehört das nicht benötigte aus dem DOM entfernt (aem.live). Bildgrößen optimiert die Plattform laut Adobe automatisch (aem.live FAQ).
Abnahmekriterien für Bilder auf AEM: LCP-Bild, Format und Abmessungen
- Das LCP-Element jedes Seitentyps ist benannt; ist es ein Bild, lädt es ohne Lazy Loading und mit
fetchpriority="high". - Der Content-Type ausgelieferter Bilder zeigt AVIF oder WebP, wo der Browser es unterstützt.
- Jedes Bild trägt Breite und Höhe; die gelieferte Breite passt zur dargestellten.
- Im Real User Monitoring werden Ladebeginn und Ladedauer des LCP-Bildes je Seitentyp ausgewertet.
Wie das CDN die Ladedauer verkürzt und welche Ursachen auf AEM-Plattformen sonst wirken, beschreiben die Seiten zum CDN und zu Adobe Experience Manager Performance.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen, ob Ihr Hauptbild am Format, an der Größe oder am Ladebeginn scheitert.
Häufige Fragen zu AEM Dynamic Media
Liefert Dynamic Media automatisch AVIF und WebP aus?
Mit Smart Imaging ja: Dynamic Media wählt bei jeder Anfrage das effizienteste Format, das der Browser unterstützt. Voraussetzung ist das von Adobe mitgelieferte CDN. Ein fest eingetragenes Format in der Bildadresse, etwa fmt=webp, übersteuert diese Aushandlung und gehört deshalb geprüft.
Sollte das LCP-Bild mit fetchpriority geladen werden?
Ja, aber nur dieses eine Bild. Mit fetchpriority="high" fordert der Browser es vor anderen Bildern an. Bekommen viele Bilder hohe Priorität, verliert das Attribut seine Wirkung. Lazy Loading und hohe Priorität am selben Bild widersprechen sich.
Warum ist ein Bild trotz Dynamic Media zu groß?
Meist wegen einer Bildvorgabe mit fester Breite, eines fehlenden srcset oder einer Pixeldichte-Anpassung ohne Obergrenze. Dynamic Media liefert, was die Adresse verlangt. Ob die gelieferte Breite zur dargestellten passt, zeigt ein Vergleich im Browser je Seitentyp und Gerät.
Hilft Dynamic Media bei einer langsamen Antwortzeit des Servers?
Nein. Dynamic Media verkürzt die Ladedauer des Bildes, die Antwortzeit des HTML bleibt davon unberührt. Liegt sie über 800 Millisekunden, beginnt die Arbeit beim Dispatcher-Cache, weil jedes Bild erst nach dem Dokument angefordert wird.