Ein Smartphone mit 360 Pixel breitem Viewport benötigt meistens nicht dieselbe Bilddatei wie ein großer Desktop. Trotzdem wird häufig eine einzige große Datei an alle Geräte ausgeliefert und anschließend nur per CSS kleiner dargestellt.
srcset und sizes lösen dieses Problem. Sie geben dem Browser mehrere echte Bildvarianten und genügend Informationen, um selbst eine geeignete Quelle auszuwählen.
Das Grundproblem
Angenommen, ein Artikelbild wird:
- auf kleinen Smartphones fast 100 % der Viewport-Breite,
- auf Tablets ungefähr 700 Pixel,
- auf Desktop maximal 1.000 Pixel
breit dargestellt.
Eine einzelne 2.400-Pixel-Datei ist für viele Geräte unnötig groß. Eine einzelne 600-Pixel-Datei ist auf großen oder hochauflösenden Displays möglicherweise zu klein.
Die Lösung besteht aus mehreren Breiten.
srcset mit Breitenangaben
Beispiel:
<img
src="bild-800.webp"
srcset="
bild-480.webp 480w,
bild-800.webp 800w,
bild-1200.webp 1200w,
bild-1600.webp 1600w
"
alt=""
>
Die Werte 480w, 800w usw. beschreiben die intrinsische Breite der jeweiligen Datei.
Der Browser kennt damit die Kandidaten.
sizes beschreibt die erwartete Anzeigegröße
Der Browser muss zusätzlich wissen, wie breit das Bild im Layout ungefähr dargestellt wird.
Beispiel:
sizes="(max-width: 768px) 100vw, 800px"
Das bedeutet vereinfacht:
- bis 768 Pixel Viewport: Bild ungefähr so breit wie der Viewport;
- darüber: ungefähr 800 CSS-Pixel.
sizes ist keine Anweisung, welche Datei geladen werden soll. Es beschreibt die Layoutgröße, die der Browser für seine Auswahl verwenden kann.
Warum der Browser selbst auswählt
Der Browser kennt Informationen, die der Server beim HTML-Generieren oft nicht vollständig kennt:
- Viewportbreite,
- Pixeldichte,
- Cache,
- teilweise Netzwerkbedingungen,
- unterstützte Formate.
Darum ist es sinnvoll, Kandidaten bereitzustellen und die Auswahl dem Browser zu überlassen.
Pixeldichte einbeziehen
Ein Bild, das 400 CSS-Pixel breit angezeigt wird, kann auf einem Gerät mit devicePixelRatio: 2 von ungefähr 800 Bildpixeln profitieren.
Der Browser berücksichtigt diesen Faktor bei der Kandidatenauswahl.
w-Deskriptoren vs x-Deskriptoren
Neben Breitenangaben wie 800w gibt es Dichteangaben:
srcset="logo.png 1x, logo@2x.png 2x"
x-Deskriptoren eignen sich gut, wenn die CSS-Anzeigegröße praktisch fest ist, beispielsweise bei Icons oder Logos.
Für flexible Content-Bilder sind w-Deskriptoren meist geeigneter.
sizes muss das echte Layout widerspiegeln
Ein häufiger Fehler ist:
sizes="100vw"
obwohl das Bild auf Desktop in einer schmalen Content-Spalte liegt.
Dann überschätzt der Browser die benötigte Bildbreite und lädt möglicherweise eine zu große Datei.
sizes sollte daher die tatsächlichen CSS-Bedingungen möglichst realistisch beschreiben.
Beispiel mit Content-Spalte
sizes="
(max-width: 640px) 100vw,
(max-width: 1024px) 80vw,
960px
"
Das ist nur sinnvoll, wenn diese Werte das reale Layout ungefähr treffen.
src bleibt wichtig
Das normale src dient als Baseline und Fallback:
src="bild-800.webp"
Browser mit srcset können dennoch einen anderen Kandidaten wählen.
Echte Varianten erzeugen
Es reicht nicht, dieselbe Datei unter verschiedenen Namen anzubieten. Jede Quelle sollte tatsächlich die angegebene Pixelbreite besitzen.
Mit dem Bildgrößen-Werkzeug können Varianten erzeugt werden. Der Seitenverhältnis-Rechner hilft bei proportionalen Abmessungen.
Welche Breiten wählen?
Zu viele Varianten erhöhen Build- und Speicheraufwand. Zu wenige können große Sprünge erzeugen.
Eine typische Reihe könnte beispielsweise sein:
480, 768, 1024, 1440, 1920
Die optimale Auswahl hängt vom Layout und von der tatsächlichen Nutzung ab.
Nicht blind Geräteklassen nachbauen
Versuche nicht, für jedes Smartphone-Modell eine eigene Bildbreite zu definieren.
Orientiere dich an Layout-Breakpoints und sichtbaren Größen, nicht an Marketingnamen von Geräten.
Art Direction mit <picture>
Manchmal soll nicht nur die Auflösung wechseln, sondern der Bildausschnitt.
Beispiel: Auf Desktop wird ein breites Banner gezeigt, mobil ein enger Portrait-Crop.
Dafür eignet sich <picture>:
<picture>
<source media="(max-width: 640px)" srcset="portrait.webp">
<img src="landscape.webp" alt="">
</picture>
Das ist Art Direction, nicht nur Auflösungswahl.
<picture> kann auch moderne Formate anbieten:
<picture>
<source type="image/avif" srcset="bild.avif">
<source type="image/webp" srcset="bild.webp">
<img src="bild.jpg" alt="">
</picture>
Format- und Größenwahl lassen sich kombinieren.
Eine 480-Pixel-Datei kann immer noch schlecht komprimiert sein.
Deshalb gehören Formatwahl und Kompression zum selben Workflow.
Intrinsische width und height
Es ist sinnvoll, Breite und Höhe des Bildes im HTML anzugeben:
<img width="1200" height="800" ...>
Der Browser kann daraus das Seitenverhältnis ableiten und vor dem Laden Platz reservieren.
Das hilft, Layoutverschiebungen zu reduzieren.
CSS darf trotzdem responsive sein
HTML-Abmessungen bedeuten nicht, dass das Bild fest bleiben muss:
img {
max-width: 100%;
height: auto;
}
Die intrinsischen Werte liefern Verhältnis und Ausgangsgröße; CSS steuert das Layout.
Lazy Loading
Nicht sofort sichtbare Bilder können häufig mit:
loading="lazy"
verzögert geladen werden.
Für ein wichtiges Hero- oder LCP-Bild ist blindes Lazy Loading dagegen oft kontraproduktiv.
LCP-Bilder priorisieren
Das größte sichtbare Bild im oberen Bereich kann das Largest Contentful Paint beeinflussen.
Für solche Bilder sind:
- passende Größe,
- frühe Entdeckung,
- geeignetes Format,
- keine unnötige Lazy-Verzögerung
besonders wichtig.
Mehr dazu im Leitfaden Bilder für Webperformance optimieren.
DPR ist nicht der einzige Faktor
Ein hochauflösendes Gerät braucht mehr Pixel, aber es muss nicht immer die maximal mögliche Quelle laden.
Browser wählen pragmatisch zwischen verfügbaren Kandidaten.
Deshalb sollte das srcset eine vernünftige Abstufung bieten.
CSS-Hintergrundbilder
srcset gilt für <img> und verwandte Mechanismen. CSS-Hintergrundbilder benötigen andere Strategien, etwa Media Queries oder image-set().
Für inhaltlich bedeutende Bilder ist <img> meist auch semantisch besser geeignet.
Accessibility bleibt unabhängig
Responsive Technik ersetzt keinen alt-Text.
Ein inhaltliches Bild braucht eine passende alternative Beschreibung. Ein dekoratives Bild sollte entsprechend behandelt werden.
Debugging im Browser
In DevTools lässt sich prüfen:
- welche Datei geladen wurde,
- ihre tatsächliche Breite,
- Netzwerkgröße,
- DPR,
- Layoutgröße.
Das ist wichtig, weil die Auswahlentscheidung nicht nur aus dem HTML-Quelltext abgelesen werden kann.
Cache kann Tests verfälschen
Wenn bereits eine große Variante im Cache liegt, kann ein Browser sie weiterverwenden.
Beim Testen von srcset sollte der Cache berücksichtigt oder deaktiviert werden.
Ein sinnvoller Workflow
- maximale Layoutgrößen bestimmen;
- hochwertige Quelle wählen;
- einige sinnvolle Breiten erzeugen;
- jede Variante passend komprimieren;
srcset definieren;sizes an das echte Layout anpassen;- width/height für das Seitenverhältnis setzen;
- LCP-Bilder priorisieren;
- unterhalb des Folds Lazy Loading nutzen;
- im echten Browser überprüfen.
Fazit
srcset beschreibt welche Bilddateien verfügbar sind. sizes beschreibt wie groß das Bild im Layout voraussichtlich erscheint. Der Browser kombiniert diese Informationen mit Pixeldichte und Viewport und wählt eine passende Quelle.
Die Technik funktioniert am besten als Teil einer vollständigen Bildstrategie: richtige Abmessungen, geeignetes Format, gute Kompression und reales Performance-Testing.
