Responsive Images im Detail: srcset, sizes, picture

1. srcset mit Width-Deskriptoren (w): dem Browser die Bildgröße mitteilen

Der w-Deskriptor in srcset beschreibt nicht die Anzeigegröße eines Bildes, sondern dessen tatsächliche intrinsische Pixelbreite in der Bilddatei. Eine Angabe wie bild-800.jpg 800w sagt dem Browser: diese Datei ist 800 Pixel breit, unabhängig davon, wie groß sie später auf dem Bildschirm dargestellt wird. Das ist der zentrale Unterschied zu Pixel-Density-Deskriptoren, die auf ein CSS-Pixel-Verhältnis referenzieren. Width-Deskriptoren eignen sich für Bilder, deren Darstellungsgröße mit dem Viewport oder dem Grid-Layout variiert, etwa Produktbilder in einem responsiven Grid, das je nach Bildschirmbreite zwei, drei oder vier Spalten anzeigt.

Damit der Browser aus mehreren w-Kandidaten sinnvoll wählen kann, braucht er zusätzlich das sizes-Attribut, das die tatsächliche Darstellungsbreite beschreibt. Ohne sizes nimmt der Browser an, das Bild fülle die gesamte Viewport-Breite, was bei einem Grid mit vier Spalten zu einer massiven Überauswahl führt. Die Kombination aus mehreren w-Werten und passendem sizes ist deshalb kein optionales Detail, sondern die Grundvoraussetzung dafür, dass Width-Deskriptoren überhaupt korrekt funktionieren.

In der Praxis generiert man für ein Grid-Bild typischerweise vier bis sechs Breiten, die sich an den relevanten Breakpoints orientieren, nicht an willkürlichen Zweierpotenzen. Ein Sprung von 400 auf 1600 Pixel deckt die Fläche zwischen mobilem Grid und großem Desktop-Grid ab, inklusive Retina-Displays, ohne unnötig viele Varianten vorzuhalten.

<!-- Product grid image: width descriptors + sizes matching the actual grid layout -->
<img
  src="/media/catalog/product/cache/large/sample-product.jpg"
  srcset="
    /media/catalog/product/cache/400/sample-product.jpg 400w,
    /media/catalog/product/cache/800/sample-product.jpg 800w,
    /media/catalog/product/cache/1200/sample-product.jpg 1200w,
    /media/catalog/product/cache/1600/sample-product.jpg 1600w
  "
  sizes="(min-width: 1024px) 33vw, (min-width: 640px) 50vw, 100vw"
  width="1200"
  height="1200"
  alt="Product name"
  loading="lazy"
>

2. srcset mit Pixel-Density-Deskriptoren (x): feste Elemente in hoher Auflösung

Der x-Deskriptor ist die ältere, einfachere Variante von srcset und eignet sich für Elemente, deren Darstellungsgröße fix ist und sich nicht mit dem Layout verändert, etwa ein Logo, ein Icon oder ein Avatar-Bild in konstanter Pixelgröße. Statt der intrinsischen Breite gibt x das Verhältnis zur nominalen CSS-Größe an: logo@2x.png 2x bedeutet, dass diese Datei für Geräte mit einem Device Pixel Ratio von 2 gedacht ist. Der Browser vergleicht ausschließlich den devicePixelRatio des Geräts mit den verfügbaren Deskriptoren und ignoriert dabei vollständig die Viewport-Breite.

Ein entscheidender Vorteil von x-Deskriptoren: sie benötigen kein sizes-Attribut, weil keine Layout-Berechnung stattfindet. Das macht sie einfacher zu pflegen, aber auch weniger flexibel. Sobald ein Element seine Darstellungsgröße je nach Viewport ändert, etwa ein Hero-Icon, das auf Mobile kleiner ist als auf Desktop, ist x die falsche Wahl. Der Browser würde weiterhin nur nach Pixeldichte optimieren, nicht nach Layoutgröße, und liefert dann in vielen Fällen ein zu kleines oder zu großes Bild für den jeweiligen Kontext aus.

Faustregel aus der Praxis: x für Bilder mit fixer CSS-Größe wie Logos und Badges, w plus sizes für alles, was sich fluide mit dem Layout mitskaliert, also praktisch jedes Produktbild, Hero-Bild und Content-Bild in einem Magento-Shop.

<!-- Fixed-size logo: pixel-density descriptors, no sizes attribute needed -->
<img
  src="/media/logo/brand-logo.png"
  srcset="
    /media/logo/brand-logo.png 1x,
    /media/logo/brand-logo@2x.png 2x,
    /media/logo/brand-logo@3x.png 3x
  "
  width="160"
  height="48"
  alt="Brand logo"
>

3. Das sizes-Attribut: wie der Browser die passende Quelle berechnet

Das sizes-Attribut ist eine Liste von Media-Condition/Wert-Paaren, die beschreibt, wie breit das Bild bei verschiedenen Viewport-Bedingungen tatsächlich dargestellt wird, zum Beispiel (min-width: 1024px) 33vw, 100vw. Wichtig ist: der Browser wertet sizes bereits während des HTML-Parsings aus, lange bevor CSS vollständig angewendet und das finale Layout berechnet ist. Das bedeutet, sizes muss die Layoutbreite vorhersagen, nicht messen. Bei komplexen CSS-Grid- oder Flexbox-Layouts mit variabler Spaltenzahl ist das eine bewusste Annäherung, keine exakte Berechnung.

Der eigentliche Auswahlalgorithmus läuft in drei Schritten ab: Erstens ermittelt der Browser aus der sizes-Liste die erste zutreffende Media-Condition und deren Wert, zum Beispiel 50vw bei einer Viewport-Breite von 900 Pixeln. Zweitens multipliziert er diesen Wert mit der aktuellen Viewport-Breite und dem devicePixelRatio des Geräts, woraus sich die effektive Zielbreite in physischen Pixeln ergibt. Drittens wählt er aus den w-Kandidaten in srcset den kleinsten Kandidaten, der diese Zielbreite noch erreicht oder übertrifft. Ist kein Kandidat groß genug, wird der größte verfügbare verwendet.

Ein häufig übersehener Punkt: Chrome, Firefox und Safari dürfen laut Spezifikation zusätzliche Heuristiken anwenden, etwa bei langsamer Netzwerkverbindung bewusst eine kleinere Variante wählen (Save-Data-Header, Chrome Lite Mode). Die sizes-Berechnung liefert also eine Zielgröße, keine Garantie für exakt diese Datei.

4. Das picture-Element für Art Direction: unterschiedliche Bildausschnitte je Breakpoint

Während srcset und sizes immer dieselbe Bildkomposition in unterschiedlichen Auflösungen liefern, löst das picture-Element ein anderes Problem: unterschiedliche Bildausschnitte oder Seitenverhältnisse je nach Viewport, bekannt als Art Direction. Ein typisches Beispiel ist ein Kampagnen-Hero, der auf Desktop ein breites Panoramabild zeigt, auf Tablet einen quadratischen Ausschnitt und auf Mobile ein hochformatiges Portrait mit dem Motiv im Fokus. Das ist kein Skalierungsproblem, sondern ein Kompositionsproblem, das srcset allein nicht lösen kann, weil dort dieselbe Bilddatei nur in verschiedenen Größen vorliegt.

Der Browser wertet die <source>-Elemente in Dokumentreihenfolge aus und verwendet die erste Quelle, deren media-Bedingung zutrifft. Das <img>-Element am Ende ist dabei nicht optional: es liefert das Fallback-Bild für Browser ohne picture-Unterstützung und definiert gleichzeitig alle gemeinsamen Attribute wie alt, width, height und loading. Innerhalb jeder <source> kann zusätzlich ein eigenes srcset mit mehreren Auflösungsvarianten stehen, sodass Art Direction und Skalierung kombiniert werden.

<!-- Art direction: different crop per breakpoint, not just different resolution -->
<picture>
  <source media="(min-width: 1024px)" srcset="/media/wysiwyg/hero-wide.jpg">
  <source media="(min-width: 640px)" srcset="/media/wysiwyg/hero-square.jpg">
  <img
    src="/media/wysiwyg/hero-portrait.jpg"
    alt="Campaign hero"
    width="800"
    height="1000"
    fetchpriority="high"
  >
</picture>

5. Das picture-Element für Format-Fallback: AVIF, WebP, JPEG

Der zweite große Anwendungsfall für picture ist der Format-Fallback: moderne, effizientere Bildformate wie AVIF oder WebP anbieten, ohne ältere Browser oder Clients ohne Unterstützung auszuschließen. Statt der media-Bedingung nutzt man hier das type-Attribut auf jeder <source>, zum Beispiel type="image/avif". Der Browser prüft jede Quelle in Reihenfolge auf Formatunterstützung und lädt die erste, die er dekodieren kann. AVIF erreicht bei vergleichbarer visueller Qualität oft 30 bis 50 Prozent kleinere Dateigrößen als JPEG, WebP liegt meist dazwischen, und JPEG bleibt als universeller Fallback am Ende der Liste.

Wichtig ist, dass jede Format-Quelle ihr eigenes srcset mit mehreren Breiten und idealerweise auch ein eigenes sizes mitbringt, sonst geht die Format-Optimierung auf Kosten der Größenoptimierung. In Magento-Shops lässt sich das über den Media-Storage-Adapter automatisieren, der beim Bild-Upload zusätzlich zu den JPEG-Originalen AVIF- und WebP-Varianten in denselben Breitenstufen generiert und cached. Fehlt eine dieser Varianten, fällt der Browser automatisch auf die nächste Quelle zurück, ohne dass es zu einem sichtbaren Fehler kommt.

<!-- Format fallback: AVIF first, then WebP, then JPEG as universal fallback -->
<picture>
  <source
    type="image/avif"
    srcset="
      /media/catalog/product/cache/800/sample.avif 800w,
      /media/catalog/product/cache/1600/sample.avif 1600w
    "
    sizes="(min-width: 1024px) 33vw, 100vw"
  >
  <source
    type="image/webp"
    srcset="
      /media/catalog/product/cache/800/sample.webp 800w,
      /media/catalog/product/cache/1600/sample.webp 1600w
    "
    sizes="(min-width: 1024px) 33vw, 100vw"
  >
  <img
    src="/media/catalog/product/cache/800/sample.jpg"
    width="800"
    height="800"
    alt="Product name"
    loading="lazy"
  >
</picture>

6. Die richtigen Bildvarianten für einen Magento-Produktkatalog generieren

Ein Magento-Produktkatalog mit mehreren tausend Artikeln stellt eine besondere Herausforderung dar: Für jedes Produktbild müssen mehrere Breiten und idealerweise mehrere Formate vorgehalten werden, ohne den Storage und die Cache-Warmup-Zeit explodieren zu lassen. Der pragmatische Ansatz ist, sich an den tatsächlich vorkommenden Layoutbreiten zu orientieren: Produktlistenbilder in einem 2- bis 4-spaltigen Grid, Galeriebilder auf der Produktdetailseite und Thumbnails im Mini-Cart brauchen jeweils unterschiedliche Breitenstufen, weil sich ihre sizes-Werte fundamental unterscheiden.

Statt Bildvarianten bei jedem Request on-the-fly zu berechnen, generiert man sie beim Produkt-Import oder Media-Upload einmalig und cached sie im pub/media/catalog/product/cache-Verzeichnis, adressiert über einen Cache-Key aus Bildpfad und Breite. Ein sinnvoller Satz für Produktlistenbilder ist [280, 400, 560, 800, 1200], für Galeriebilder auf der Detailseite eher [600, 900, 1200, 1800]. Diese Werte werden nicht geraten, sondern aus den tatsächlichen Tailwind-Breakpoints und Grid-Spaltenzahlen des Themes abgeleitet.

Der folgende Ausschnitt zeigt das Grundmuster für ein Hyvä-phtml-Template, das srcset dynamisch aus einer Breitenliste zusammensetzt, statt jede Variante hart zu codieren.

<?php
/** @var \Magento\Catalog\Block\Product\ListProduct $block */
/** @var \Magento\Framework\Escaper $escaper */
$widths = [280, 400, 560, 800, 1200];
$srcset = implode(', ', array_map(
    static fn (int $w): string => "{{\$block->getProductImageUrl(\$product, $w)}} {$w}w",
    $widths
));
?>
<img
    src="{{$block->getProductImageUrl($product, 400)}}"
    srcset="<?= $escaper->escapeHtmlAttr($srcset) ?>"
    sizes="(min-width: 1280px) 25vw, (min-width: 768px) 33vw, 50vw"
    width="400"
    height="400"
    alt="{{$escaper->escapeHtmlAttr($product->getName())}}"
    loading="lazy"
>

7. Der häufigste Fehler: fehlendes sizes und die Worst-Case-Auswahl

Der mit Abstand häufigste Fehler in Responsive-Image-Implementierungen ist ein srcset mit mehreren w-Kandidaten ohne begleitendes sizes-Attribut. Fehlt sizes, greift die Spezifikation auf einen Default-Wert zurück: sizes="100vw". Der Browser geht also davon aus, das Bild werde über die volle Viewport-Breite dargestellt, selbst wenn es tatsächlich nur eine 25-Prozent-Spalte in einem vierspaltigen Grid füllt. Das Resultat ist die Worst-Case-Auswahl: Auf einem 1600 Pixel breiten Desktop-Viewport lädt der Browser die größte verfügbare Variante, obwohl das Bild visuell nur 400 Pixel breit dargestellt wird, ein Overhead von mehreren hundert Kilobyte pro Bild, multipliziert mit jedem Produkt im Grid.

Dieser Fehler ist besonders tückisch, weil er in DevTools nicht sofort aussieht wie ein Fehler, das Bild lädt ja korrekt und sieht scharf aus. Sichtbar wird er erst über die Network-Tabelle, wenn man die tatsächlich transferierte Dateigröße mit der gerenderten CSS-Größe des Elements vergleicht, oder über das Lighthouse-Audit „Richtig dimensionierte Bilder“, das genau diese Diskrepanz aufdeckt. Die Regel ist einfach: sobald srcset mehr als einen w-Kandidaten enthält, ist sizes verpflichtend zu pflegen und muss bei jeder Layoutänderung des Grids mit aktualisiert werden.

8. Lazy Loading im Zusammenspiel mit srcset und sizes

Das native loading="lazy"-Attribut arbeitet vollständig unabhängig von srcset und sizes, beide Mechanismen greifen nacheinander: Erst entscheidet loading, wann der Browser überhaupt beginnt, eine Bildquelle anzufordern, dann entscheiden srcset und sizes, welche Quelle das ist. Für Bilder unterhalb des sichtbaren Bereichs ist loading="lazy" auf jedem img und jedem source innerhalb eines picture sinnvoll und reduziert initiale Netzwerklast spürbar, gerade auf langen Kategorieseiten mit vielen Produktbildern.

Für das jeweils größte, sofort sichtbare Element, meist das LCP-Bild einer Seite, gilt das Gegenteil: loading="lazy" darf hier nicht gesetzt werden, weil der Browser dann erst nach dem Layout-Scan mit dem Laden beginnt, statt es sofort mit hoher Priorität anzustoßen. In Kombination mit fetchpriority="high" und einem <link rel="preload"> im Head lässt sich das LCP-Bild gezielt vor allen anderen Bildern laden. Ein häufiger Fehler ist, dieselbe Lazy-Loading-Regel pauschal auf alle Bilder eines Templates anzuwenden, statt zwischen dem kritischen ersten Bild und allen nachfolgenden Bildern zu unterscheiden.

9. Responsive-Images-Patterns im direkten Vergleich

Die folgende Übersicht fasst die häufigsten Fehlmuster bei Responsive Images den jeweils korrekten Patterns gegenüber, mit dem konkreten Effekt auf Ladezeit und Bildqualität.

Die Tabelle zeigt ein durchgängiges Muster: Fast jeder Fehler bei Responsive Images entsteht dadurch, dass eine Information, die der Browser zur Auswahl braucht, entweder fehlt oder nicht zum tatsächlichen Layout passt. Wer sizes konsequent aus den echten CSS-Breakpoints ableitet und picture ausschließlich für Art Direction und Format-Fallback reserviert, vermeidet die überwiegende Mehrheit dieser Probleme automatisch.

10. Zusammenfassung

Responsive Images lösen ein Optimierungsproblem, keine Layoutfrage: Sie sorgen dafür, dass jedes Gerät genau die Bilddatei lädt, die es für die tatsächliche Darstellungsgröße braucht, nicht mehr und nicht weniger. srcset mit w-Deskriptoren plus einem präzisen sizes-Attribut deckt den weit überwiegenden Teil aller Fälle ab, von Produktgrids bis zu Content-Bildern. x-Deskriptoren bleiben Elementen mit fixer Darstellungsgröße vorbehalten, etwa Logos. Das picture-Element ist kein Ersatz für srcset, sondern ergänzt es gezielt dort, wo sich entweder die Bildkomposition (Art Direction) oder das Dateiformat (AVIF/WebP/JPEG) je nach Kontext unterscheiden muss.

Der größte Hebel liegt darin, sizes nicht als Nebensache zu behandeln, sondern konsequent aus den tatsächlichen CSS-Breakpoints des Themes abzuleiten und bei jeder Layoutänderung zu aktualisieren. Für Magento-Produktkataloge lohnt sich eine automatisierte Variantenpipeline, die beim Media-Upload feste Breitenstufen pro Bildtyp generiert, statt Bildgrößen manuell zu pflegen oder dem Browser mit fehlendem sizes die Worst-Case-Auswahl zu überlassen.

11. FAQ: Responsive Images im Detail