Zu große Bilder trotz srcset: sizes richtig setzen

Die Auswahl läuft in drei Schritten. Zuerst geht der Browser die Liste in sizes von links nach rechts durch und nimmt die erste Medienbedingung, die zutrifft; der Eintrag ohne Bedingung am Ende gilt, wenn keine passt (MDN Web Docs). Diese Breite ist der Platz, den das Bild im Layout bekommt. Danach teilt er jede w-Angabe aus srcset durch diese Breite. Aus 800w bei einem Platz von 400 Pixeln wird so eine effektive Dichte von 2. Zuletzt vergleicht er diese Dichten mit der Pixeldichte des Geräts und lädt die Datei, die am ehesten passt.

Weil die erste zutreffende Bedingung gewinnt, entscheidet die Reihenfolge. MDN formuliert es deutlich: Der Browser ignoriert alles nach der ersten passenden Bedingung (MDN Web Docs). Wer (min-width: 576px) 50vw vor (min-width: 1200px) 300px schreibt, bekommt auf dem Desktop die halbe Fensterbreite, weil die erste Bedingung dort ebenfalls zutrifft. Bei min-width gehört die breiteste Bedingung nach vorn, bei max-width die schmalste.

Die folgende Tabelle rechnet das für eine Listing-Kachel mit einem srcset aus vier Stufen durch: 400, 600, 1000 und 1600 Pixel. Es ist ein Rechenbeispiel; der Browser darf im Einzelfall anders entscheiden, wie der Abschnitt danach zeigt.

Die Pixeldichte ist der Teil, den viele unterschätzen. Eine Datei mit doppelter Breite hat viermal so viele Pixel, und die Dateigröße wächst mit. Im Beispiel von MDN wiegt dasselbe Motiv mit 640 Pixeln Breite 93 KB, mit 320 Pixeln 39 KB (MDN Web Docs). Deshalb macht sizes auf hochauflösenden Smartphones so viel aus: Jeder Fehler in der angegebenen Breite wird mit der Pixeldichte multipliziert, und aus einem kleinen Irrtum im Markup wird eine deutlich größere Datei.

Der Standard lässt dem Browser bei der Auswahl Spielraum. Er darf neben der Pixeldichte auch Zoomstufe und Netzbedingungen berücksichtigen (HTML Living Standard), und der eigentliche Auswahlschritt ist ausdrücklich der Implementierung überlassen (HTML Living Standard). Praktisch heißt das: Liegt eine größere Fassung desselben Bildes schon im Speicher, kann der Browser sie wiederverwenden. In einem Test mit Chrome lud ein lazy geladenes Bild mit sizes="auto" in den meisten Durchläufen die große Datei, weil dasselbe Motiv weiter oben ohne sizes stand und die große Fassung bereits geladen hatte; allein auf der Seite lud dasselbe Bild die passende kleine Datei. Ein fehlendes sizes an einer Stelle kann also eine zweite Stelle mitziehen.

Ein passendes sizes entsteht nicht durch Ausprobieren, sondern aus dem Raster der Vorlage. Je Umbruchpunkt braucht es vier Angaben: die Spaltenzahl, den Abstand zwischen den Spalten, den seitlichen Rand und die maximale Breite des Inhaltsbereichs. Daraus ergibt sich die Breite einer Spalte, und genau diese Breite steht als Ausdruck in sizes. Wer seine Seiten ohnehin nach Vorlagen gliedert, wie im Beitrag Vorlage statt Startseite beschrieben, hat die Liste der Bildstellen schon fast beisammen. Für eine Listing-Kachel sieht das Ergebnis so aus:

Zwei Feinheiten machen den Unterschied. Erstens darf sizes etwas größer sein als die echte Breite, aber nicht deutlich kleiner: Ein zu kleiner Wert führt zu einer Datei, die der Browser hochskaliert, und das Bild wirkt unscharf. Der Almanac nennt sizes ausdrücklich einen Hinweis, bei dem eine kleine Ungenauigkeit in Ordnung ist (Web Almanac 2024). Zweitens folgt ein Ausdruck mit calc() dem Fenster stufenlos, während ein fester Pixelwert zwischen zwei Umbruchpunkten zwangsläufig zu groß oder zu klein ist. Feste Werte eignen sich deshalb vor allem oberhalb der maximalen Containerbreite.

Für Shopware-Themes heißt das konkret: Die Werte für die Listing-Kachel stehen in einer Vorlage der Storefront, die ein eigenes Theme überschreiben kann. Wer das Raster ändert, passt diese Werte im selben Schritt an, statt sie aus dem Standard zu übernehmen. Weitere Stellschrauben im Theme fasst die Seite Shopware-Performance zusammen.

Für Bilder außerhalb des ersten Bildschirms gibt es inzwischen eine Abkürzung. Mit sizes="auto" nimmt der Browser die Breite aus dem berechneten Layout, statt sie aus einer Liste zu lesen; das gilt nur für Bilder mit loading="lazy" (Web Features Explorer). Der HTML-Standard verlangt, dass auto als erster Eintrag steht, und erlaubt dahinter eine Rückfallliste für Browser ohne Unterstützung (HTML Living Standard). Ohne width und height oder eine Breite im CSS wird ein solches Bild voraussichtlich mit 300 × 150 Pixeln dargestellt (HTML Living Standard).

Ausgewertet wird auto laut MDN browser-compat-data in Chrome ab Version 126, in Firefox ab Version 150 und in Safari ab Version 27, dort mit einer Einschränkung bei SVG-Bildern mit object-fit (MDN browser-compat-data). Manche Übersichtsseiten führen Safari noch ohne Unterstützung; mit Rückfallliste spielt der Unterschied in der Praxis keine Rolle, denn ältere Versionen lesen die Liste hinter auto. Für das LCP-Bild hilft auto nicht, weil es nicht lazy laden soll; es braucht weiterhin eine ausdrückliche Liste. Der Almanac rät genau dazu: kritische Bilder korrigieren und für nachgeladene Bilder auto einsetzen (Web Almanac 2024). Wie das in der Vorschauleiste einer Produktseite aussieht, steht ebenfalls im Beitrag zur Produktgalerie.

Ein passendes sizes spart Übertragung, ohne dass ein Bild schlechter aussieht. Wie viel, hängt vom Ausgangspunkt ab. Nach der Schätzung des Almanac lädt ein Viertel der Desktopseiten mit w-Angaben 180 KB oder mehr zu viel, mindestens die Hälfte dieser Seiten dagegen nichts (Web Almanac 2024). Ob Ihr Shop zur ersten oder zur zweiten Gruppe gehört, zeigt die Messung je Vorlage.

Grenzen hat die Korrektur dort, wo das Problem nicht die Breite ist. Format und Kompression stehen auf einem anderen Blatt; dazu mehr im Beitrag über WebP und AVIF. Auch die Reihenfolge des Ladens ändert sizes nicht: Ein LCP-Bild, das spät entdeckt oder lazy geladen wird, bleibt spät, auch wenn die Datei klein ist. Und ob die Verbesserung bei echten Besuchern ankommt, zeigen erst Felddaten, etwa im Core-Web-Vitals-Bericht der Search Console.

Bei einer Bildoptimierung gehen wir genau diesen Weg: Wir listen die Bildstellen je Vorlage, messen geladene gegen benötigte Breite bei mehreren Fensterbreiten und Pixeldichten, leiten sizes aus dem Raster ab und messen danach erneut. In Shopware-Shops passen wir dafür die Vorlagen des Themes an. Wenn Sie zuerst wissen möchten, wo Ihr Shop steht, beginnt das mit einer Analyse der wichtigsten Vorlagen. Welche Messgrößen dabei zählen, erklärt die Seite zu den Core Web Vitals.