Bilder und Videos im Headless-Frontend ausliefern: der praktische Guide

Die Entscheidung für ein Image- und Video-CDN ist bei den meisten Teams längst gefallen. Die eigentliche Arbeit beginnt danach: richtige Formate pro Browser, Breakpoint-Sets, die zum tatsächlichen Layout passen, Lazy-Loading ohne LCP-Schaden und eine Messung, die zeigt, ob es wirkt. Dieser Guide geht das entlang Shopware, commercetools und Shopify konkret durch, kein Vendor-Vergleich, sondern Umsetzung.

Format-Matrix: AVIF, WebP, JPEG-Fallback

Drei Formate, drei Rollen:

• AVIF liefert die beste Kompression bei gleicher wahrgenommener Qualität, rund 30 bis 50 Prozent kleiner als vergleichbares WebP (Beispielrechnung, abhängig von Bildinhalt). Unterstützt in aktuellem Chrome, Firefox, Edge und Safari ab Version 16.4.
• WebP ist der breite Fallback: Support seit Jahren in allen relevanten Browsern, auch in älteren Safari-Versionen vor 16.4.
• JPEG bleibt der letzte Fallback für E-Mail-Clients, PDF-Export-Tools oder alte Crawler, die weder AVIF noch WebP parsen.

In der Praxis heißt das ein <picture>-Element mit drei Quellen, Browser wählt selbst:

<picture>
  <source type="image/avif" srcset="/img/sneaker-p-400.avif 400w, /img/sneaker-p-800.avif 800w, /img/sneaker-p-1200.avif 1200w">
  <source type="image/webp" srcset="/img/sneaker-p-400.webp 400w, /img/sneaker-p-800.webp 800w, /img/sneaker-p-1200.webp 1200w">
  <img src="/img/sneaker-p-800.jpg" srcset="/img/sneaker-p-400.jpg 400w, /img/sneaker-p-800.jpg 800w, /img/sneaker-p-1200.jpg 1200w"
       sizes="(min-width: 992px) 660px, 100vw" width="800" height="800" loading="lazy" decoding="async"
       alt="Sneaker Produktdetail, Seitenansicht">
</picture>

width/height sind Pflicht, auch wenn srcset variable Breiten liefert: Sie reservieren den Platz im Layout und verhindern CLS beim Bild-Load.

srcset und sizes, die zum echten Breakpoint passen

Die übliche Copy-Paste-Leiter (320, 640, 960, 1280, 1920) ignoriert, wie breit das Bild tatsächlich gerendert wird. Drei Frontends, drei unterschiedliche Antworten:

• Shopware (Storefront-Theme auf Bootstrap-Basis, Breakpoints bei 576/768/992/1200/1400px): Die PDP-Galerie rendert unter 768px auf voller Containerbreite, ab 992px in einer Zwei-Spalten-Ansicht bei rund 660px. Sinnvolle Breiten: 400, 660, 900, 1200, nicht die generische Leiter.
• commercetools-Frontends (häufig auf Next.js mit Tailwind-Default-Breakpoints, 640/768/1024/1280px): Die PLP-Grid zeigt 2 Spalten mobil, 3 im Tablet, 4 ab 1280px. Bei 4 Spalten und Gutter landet die einzelne Kachel bei rund 280px, mobil bei rund 340px. Breiten also 280, 340, 560 (2x-Variante für hochauflösende Displays).
• Shopify (Dawn/Hydrogen-Themes, Content-Max-Width meist 1600px): Der Kategorie-Hero ist full-bleed (sizes="100vw"), muss aber nicht breiter als 3200px ausgeliefert werden, selbst bei 4K-Displays, weil die Content-Breite hart gedeckelt ist. Alles darüber ist verschenkter Bytes-Transfer.

Kurz: sizes muss die reale Renderbreite je Breakpoint abbilden, nicht die Viewport-Breite. Wer sizes="100vw" überall setzt, obwohl das Bild nur in einer Spalte liegt, lädt systematisch zu große Dateien.

Für die Umsetzung ist https://www.laioutr.com/cloud/image-cdn der Ort, an dem Breiten-Sets pro Layout definiert werden, statt sie hart im Template zu pflegen.

loading und fetchpriority: wann Lazy-Loading dem LCP schadet

loading="lazy" ist Standard geworden, oft als globaler Default im Bild-Component der Frontend-Bibliothek. Genau das ist der Fehler bei einem Bild: dem LCP-Kandidaten, meist Hero-Banner oder PDP-Hauptbild.

Zwei häufige Symptome:

1. Der Bild-Component setzt loading="lazy" unabhängig von Position im Viewport. Das LCP-Bild wird dadurch erst nach dem Intersection-Check angefragt, nicht sofort beim Parsen des initialen HTML.
2. Das Bild liegt hinter data-src statt src, weil eine JS-Lazy-Loading-Library die Auflösung übernimmt. Der Browser-Preload-Scanner kann das Bild dann nicht früh erkennen, selbst wenn es above-the-fold liegt.

Für den LCP-Kandidaten gilt:

<img src="/img/hero-1200.avif" fetchpriority="high" loading="eager" decoding="async"
     width="1200" height="630" alt="Kategorie-Hero Sommerkollektion">

Zusätzlich als <link rel="preload" as="image"> im <head>, wenn das Asset erst über CSS-Background oder JS-Hydration eingebunden wird. Alles unterhalb des ersten Viewports bleibt loading="lazy", dort spart es tatsächlich Bytes.

Video: Poster-Frames, Preload-Strategie, adaptive Bitrate

Video-Elemente brauchen dieselbe Above-the-Fold-Disziplin wie Bilder:

• Poster-Frame: statisches AVIF/WebP-Standbild (per ffmpeg aus der ersten Sekunde extrahiert), reserviert Platz und verhindert CLS, während das Video noch lädt.
• Preload: preload="none" als Default für Video unterhalb des Viewports, preload="metadata" für above-the-fold-Video (lädt nur Dauer/Dimensionen, nicht den vollen Stream), preload="auto" nur für sehr kurze Loop-Assets unter 2 MB.
• Adaptive Bitrate: Für Hero-Videos ein HLS-Manifest (.m3u8) mit mehreren Renditions (z. B. 360p/720p/1080p) statt einer fixen MP4-Datei. Der Player wählt je nach gemessenem Durchsatz, statt allen Nutzern die Desktop-Qualität aufzuzwingen.

<video poster="/img/hero-poster.avif" preload="metadata" playsinline muted loop width="1200" height="630">
  <source src="/video/hero.m3u8" type="application/x-mpegURL">
  <source src="/video/hero-720p.mp4" type="video/mp4">
</video>

Wie core-web-vitals-image-video-delivery-lcp-storefront-2026 zeigt, ist der Poster-Frame oft selbst der LCP-Kandidat, nicht das Video, solange der Stream noch nicht steht.

Messen: LCP, CLS, übertragene Bytes

Drei Messpunkte, drei Werkzeuge:

• LCP: Feld-Daten über die web-vitals-JS-Library (onLCP-Callback) oder Chrome UX Report. Google-Schwellenwerte: gut bei ≤ 2,5s (75. Perzentil), verbesserungswürdig bis 4s, darüber schlecht.
• CLS: onCLS-Callback, gut bei ≤ 0,1. Reservierte width/height auf jedem Bild- und Video-Element ist der größte Hebel dagegen.
• Übertragene Bytes: Chrome-DevTools-Network-Panel gefiltert nach img/media, oder Lighthouse-Resource-Summary. Beispielrechnung: Eine PDP mit 8 Produktbildern à rund 120 KB (AVIF, 800px Breite) statt 8 × 350 KB (unkomprimiertes JPEG in Originalgröße) senkt den Bild-Transfer von rund 2,8 MB auf rund 960 KB, eine Beispielrechnung zur Größenordnung, kein garantierter Wert für jeden Katalog.

Der Post what-is-an-image-cdn-2026 erklärt die Grundlagen des Bild-CDN selbst, dieser Guide setzt bei der Umsetzung im Frontend an.

Weitere Themen aus der Laioutr-Plattform

• Image CDN
• Video CDN
• Composable Headless Frontend

FAQ

Muss ich AVIF selbst generieren? Nein, ein Image-CDN übernimmt die Format-Konvertierung on-the-fly anhand des Accept-Headers. Die Storefront liefert nur die Quelldatei einmal.

Wie viele Breakpoints brauche ich wirklich? Meist reichen 3 bis 5, orientiert an den tatsächlichen CSS-Breakpoints des Themes, nicht an Geräteklassen.

Nächste Schritte

Wer die Format-Matrix und Breakpoint-Logik direkt am eigenen Storefront durchgehen will: Composable Headless Frontend zeigt, wie Image- und Video-CDN in die Laioutr-Frontend-Ebene eingebunden sind.

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und verantwortet Produkt und Architektur der Frontend Management Platform.