Bilder komprimieren und passend ausliefern: srcset und picture

Ein Titelbild kann auf dem großen Bildschirm hervorragend aussehen und auf dem Smartphone trotzdem unnötig viele Daten übertragen. Eine stark komprimierte Datei kann klein sein und dennoch zu wenig Details für die Produktansicht enthalten. Gute Bildauslieferung verbindet deshalb drei Entscheidungen: welches Motiv gebraucht wird, wie groß es tatsächlich erscheint und welche Datei dafür geeignet ist. Ein neues Dateiformat allein erledigt diese Arbeit nicht.

Dieser Beitrag entwickelt dafür einen nachvollziehbaren Arbeitsablauf. Ein vollständiges HTML-Beispiel bietet AVIF, WebP und JPEG in mehreren Breiten an. Seine Layoutangaben wurden mit echten Bilddateien in Edge geprüft. Das Lernmotiv ist eine eigens erzeugte grafische Testfläche. Die Ergebnisse sind ein Funktionsnachweis für dieses Beispiel und keine allgemeine Messung von Fotoqualität, Ladezeit oder Einsparung. Quellen und technische Einordnung wurden am 9. November 2026 geprüft.

Mit dem Verwendungsort beginnen

Ein Bild in einer Kartenübersicht erfüllt eine andere Aufgabe als das Hauptmotiv eines ausführlichen Artikels. Die Karte braucht einen verständlichen Ausschnitt bei kleiner Darstellung. Die Detailseite kann feinere Materialeigenschaften zeigen. Ein erklärendes Diagramm muss seine Beschriftungen lesbar halten. Definiere diese Rollen, bevor ein Exportwerkzeug pauschal alle Originale in dieselbe Breite umwandelt.

Notiere für jede Rolle die größte tatsächliche Darstellungsbreite, die relevanten schmalen Ansichten und den benötigten Ausschnitt. Prüfe außerdem, ob die Besucherin das Bild vergrößern kann. Eine vergrößerte Produktansicht ist ein eigener Bedarf und muss nicht als große Datei in jede Übersicht geladen werden. Der zusätzliche Detailabruf kann an die tatsächliche Vergrößerung gebunden werden.

Diese Bestandsaufnahme verhindert zwei häufige Fehler: Ein kleines Kartenbild wird unnötig groß übertragen oder ein für Karten erzeugtes Vorschaubild wird auf der Detailseite unscharf vergrößert. Die Bildrolle gehört deshalb zur Komponente. Eine spätere Layoutänderung muss die Exportannahmen und die Angaben im HTML erneut berücksichtigen.

Pixelmaße, Dateigröße und Darstellungsgröße unterscheiden

Die Breite einer Datei beschreibt ihre vorhandenen Bildpunkte. Die Dateigröße beschreibt ihre gespeicherten Bytes. Die im Layout gemessene Breite wird dagegen in CSS-Pixeln angegeben. Diese Größen hängen zusammen, sind aber nicht austauschbar. Eine Datei mit unveränderten Pixelmaßen kann durch eine andere Kodierung weniger Bytes benötigen. Sie bleibt trotzdem für eine schmale Kartenansicht möglicherweise überdimensioniert.

Für die Planung hilft eine einfache Rechnung: Ein Bildbereich mit 360 CSS-Pixeln Breite benötigt bei einem angenommenen Verhältnis von zwei Gerätebildpunkten je CSS-Pixel rechnerisch 720 Bildpunkte in der Breite. Das ist eine Orientierung und keine Anweisung, dass jeder Browser immer exakt diese Datei laden muss. Auswahl, Zwischenspeicher und weitere Browserentscheidungen können die tatsächlich verwendete Variante beeinflussen.

Die MDN-Anleitung für responsive Bilder erklärt den Unterschied zwischen Auflösungswahl und unterschiedlichen Ausschnitten. Entscheidend für die Umsetzung ist eine ehrliche Beschreibung des verfügbaren Bildbereichs. Eine pauschale Angabe von 100 Prozent der Bildschirmbreite passt nicht zu einem Bild, das auf dem Desktop nur eine schmale Spalte ausfüllt.

Ein kleines, begründetes Größenraster festlegen

Das Beispiel verwendet 480, 960, 1440 und 1920 Bildpunkte. Diese Auswahl ist kein Standard für jede Webseite. Sie deckt die hier geplanten Bildbereiche bis 960 CSS-Pixel ab und bietet zusätzlich eine größere Variante für eine höhere Pixeldichte. Eine Webseite mit 320 Pixel breiten Karten und einem sehr breiten Panorama kann andere Zwischenstufen benötigen.

Die Tabelle enthält Geometrie aus dem Beispiel, keine Performancewerte. Ihre wichtigste Aussage ist die Begrenzung auf 960 CSS-Pixel im großen Layout. Ein breiter Bildschirm verlangt hier nicht automatisch ein ebenso breites Bild. Umgekehrt kann ein schmales Gerät mit höherer Pixeldichte eine Datei benötigen, die deutlich breiter als sein CSS-Bildbereich ist.

Formate nach dem Inhalt auswählen

Für fotografische Motive kommen verschiedene verlustbehaftete Kodierungen infrage. Für scharfe Grafiken, Transparenz und feine Schrift müssen andere Anforderungen berücksichtigt werden. Die Einführung in Rasterbilder von web.dev beschreibt diesen Zusammenhang zwischen Bildinhalt und Kompression. Aus einer kleineren Datei folgt nicht automatisch eine bessere Darstellung.

Ein Qualitätswert von 80 bedeutet nicht in jedem Format dieselbe sichtbare Qualität. Auch zwei Programme können denselben Zahlenwert unterschiedlich umsetzen. Speichere deshalb das verwendete Werkzeug und seine Einstellungen zusammen mit den Exportregeln. Ändere die Voreinstellung erst nach einem Vergleich repräsentativer Motive, statt eine einzelne gut komprimierbare Aufnahme zum Maßstab des gesamten Bestands zu machen.

Aus einem guten Original ableiten

Bewahre das brauchbare Ausgangsmaterial getrennt von den ausgelieferten Varianten auf. Neue Größen sollten aus dieser Quelle entstehen und nicht aus einer bereits mehrfach verlustbehaftet gespeicherten kleinen Datei. Ein Umbenennen von JPEG nach WebP ändert weder die Kodierung noch die Qualität. Das tatsächliche Format, die Dateiendung und der ausgelieferte Inhaltstyp müssen zusammenpassen.

Prüfe vor der Ableitung die Orientierung, den vorgesehenen Farbraum und die relevanten Bildinformationen. Ein exportiertes Bild darf nicht versehentlich gedreht erscheinen oder wesentliche Kontraste verlieren. Entferne unnötige private Metadaten aus der veröffentlichten Datei. Erforderliche Nachweise und Rechteinformationen gehören dennoch in die interne Dokumentation und dürfen nicht zusammen mit der öffentlichen Kopie verloren gehen.

Wenn das Ausgangsmaterial bereits kleiner als der geplante Export ist, erzeugt Hochskalieren keine tatsächlich neu aufgenommenen Details. Entscheide dann bewusst zwischen begrenzter Darstellung, anderem Motiv und einer geeigneten neuen Quelle. Besonders bei Text, technischen Anschlüssen oder dokumentarischen Produktansichten sind künstlich ergänzte Details kein Ersatz für den echten Beleg.

Ein vollständiges picture-Beispiel

Das folgende Beispiel beschreibt eine einzelne, direkt sichtbare Illustration. Alle Varianten zeigen denselben Ausschnitt und dasselbe Seitenverhältnis. Die Pfade gehören zu einer Lernimplementierung: Die zugehörigen Dateien müssen unter diesen Adressen tatsächlich bereitgestellt werden. Die Quellenreihenfolge bietet AVIF zuerst, danach WebP und schließlich JPEG an. Das enthaltene img-Element bleibt für Beschreibung und Rückfallquelle erforderlich.

<picture>
  <source type="image/avif"
    srcset="/bilder/detail-480.avif 480w, /bilder/detail-960.avif 960w, /bilder/detail-1440.avif 1440w, /bilder/detail-1920.avif 1920w"
    sizes="(max-width: 700px) calc(100vw - 32px), (max-width: 1100px) calc(100vw - 64px), 960px">
  <source type="image/webp"
    srcset="/bilder/detail-480.webp 480w, /bilder/detail-960.webp 960w, /bilder/detail-1440.webp 1440w, /bilder/detail-1920.webp 1920w"
    sizes="(max-width: 700px) calc(100vw - 32px), (max-width: 1100px) calc(100vw - 64px), 960px">
  <img src="/bilder/detail-960.jpg"
    srcset="/bilder/detail-480.jpg 480w, /bilder/detail-960.jpg 960w, /bilder/detail-1440.jpg 1440w, /bilder/detail-1920.jpg 1920w"
    sizes="(max-width: 700px) calc(100vw - 32px), (max-width: 1100px) calc(100vw - 64px), 960px"
    width="1920" height="1200" alt="Roter Kreis und helle Konturen auf einem dunklen Raster."
    fetchpriority="high" decoding="async">
</picture>

Die Breitenangaben mit w müssen den wirklichen Dateibreiten entsprechen. Sie sind keine gewünschten CSS-Breiten. Die Angaben unter sizes beschreiben den geplanten Bildbereich. Weil jede Formatgruppe ihre eigene Kandidatenliste besitzt, steht die passende Größenbeschreibung hier bei beiden source-Elementen und beim img-Element. Eine spätere Layoutänderung muss alle drei Stellen erreichen.

Das MDN-Referenzdokument zu picture erläutert die Auswahl nach Format und Bedingungen. Ein angebotenes Format muss zum ausgelieferten Dateityp passen. Verlasse dich nicht darauf, dass der Browser eine defekte oder fehlende bevorzugte Datei automatisch durch die nächste Formatgruppe ersetzt. Genau dieser Fehlerfall wird im später beschriebenen Versuch sichtbar.

Das CSS muss zu sizes passen

Die Bildfläche hat in der schmalen Ansicht insgesamt 32 Pixel seitlichen Abstand. Ab 701 Pixel Viewportbreite werden daraus insgesamt 64 Pixel. Oberhalb von 1100 Pixeln bleibt die Bildfläche bei 960 Pixeln. Das CSS setzt diese konkrete Geometrie um. Es ist absichtlich klein gehalten, damit die Beziehung zwischen Layout und HTML überprüfbar bleibt.

* { box-sizing: border-box; }
body { margin: 0; font-family: system-ui, sans-serif; }
.bildbereich { width: calc(100% - 32px); margin: 32px auto; }
picture { display: block; }
img { display: block; width: 100%; height: auto; }
@media (min-width: 701px) {
  .bildbereich { width: calc(100% - 64px); }
}
@media (min-width: 1101px) {
  .bildbereich { width: 960px; }
}

Das img-Element füllt den vorhandenen Bereich aus. Seine automatische Höhe bewahrt das Seitenverhältnis. Die Attribute width und height im HTML benennen die Proportion des Motivs und helfen dabei, vor dem Laden Platz vorzusehen. Sie schreiben nicht vor, dass das Bild tatsächlich 1920 CSS-Pixel breit dargestellt werden soll. Die img-Referenz von MDN beschreibt die entsprechenden Attribute.

Wenn der spätere Seitenaufbau einen Innenabstand, eine Seitenleiste oder eine maximale Textspaltenbreite ergänzt, muss die Rechnung neu geprüft werden. Ein syntaktisch gültiges sizes kann inhaltlich falsch sein. Die geeignete Kontrolle misst deshalb die tatsächliche Bildbreite im Browser und vergleicht sie mit dem beschriebenen Bereich.

Die Browserauswahl tatsächlich ansehen

Im Beispiel wurden drei Viewportbreiten, zwei Pixeldichten, drei angebotene Formatgruppen und beide Sprachfassungen kombiniert. Daraus entstehen 36 normale Testfälle. Jeder Lauf begann in einem neuen isolierten Browserkontext, damit eine bereits geladene größere Datei die Beobachtung nicht beeinflusst. Die Dateien wurden mit ihren wirklichen Inhaltstypen an den Browser ausgeliefert.

Geprüft wurden die erfolgreiche Dekodierung, die angebotene Formatgruppe, die gemessene Bildbreite, das Seitenverhältnis und der tatsächlich angeforderte Bildpfad. Hinzu kam ein Fehlerfall mit einer fehlenden bevorzugten AVIF-Datei. Insgesamt bestanden 183 einzelne Prüfbedingungen in 37 Fällen. Das ist ein Nachweis für dieses kontrollierte Beispiel und diese Edge-Ausführung, keine allgemeine Kompatibilitätsprüfung aller Geräte.

Für den WebP- und JPEG-Versuch wurden die jeweils vorgelagerten Quellen aus dem Angebot entfernt. Derselbe Browser erhielt dadurch kürzere Quellenlisten. Das simuliert nicht die vollständige Implementierung eines alten Browsers. Es überprüft, ob jede angebotene Gruppe mit den vorhandenen Dateien und dem Layout grundsätzlich funktioniert.

Warum eine Format-Rückfallquelle kein Reparaturdienst ist

Im zusätzlichen Fehlerfall bot das HTML weiterhin AVIF zuerst an. Die ausgewählte AVIF-Datei antwortete jedoch mit einem fehlenden Inhalt. In der ausgeführten Edge-Prüfung scheiterte die Dekodierung und die Bildbreite aus dekodierten Daten blieb null. Eine WebP- oder JPEG-Datei wurde nicht als automatische Reparatur nachgeladen. Dieser beobachtete Ablauf ist ein guter Grund, jede veröffentlichte Kandidatenadresse zu prüfen.

Ein häufiger Produktionsfehler entsteht durch eine unvollständige Bereitstellung: Das HTML verweist bereits auf die neue Dateiversion, während nur ein Teil der Varianten vorhanden ist. Eine andere Ursache ist eine falsche Zuordnung von Dateiendung und Inhalt. Beide Fehler bleiben möglich, auch wenn das Markup vorbildlich aussieht. Prüfe deshalb den Inhalt der ausgelieferten Dateien und nicht nur die Existenz eines Dateinamens im Exportordner.

Eine zuverlässige Veröffentlichung überträgt zuerst den vollständigen Variantensatz und schaltet anschließend das passende HTML um. Alte Dateipfade können für den vereinbarten Rückweg erhalten bleiben. Diese Reihenfolge verhindert, dass Besucher zwischen zwei technisch unvollständigen Zuständen landen.

Die richtige Variante im Werkzeug erkennen

Die Eigenschaft currentSrc zeigt den vom Browser gewählten Bildpfad. Vergleiche diesen mit den tatsächlich geladenen Netzwerkressourcen. Die CSS-Breite erhältst du über die gemessene Elementfläche. naturalWidth allein ist dafür kein Ersatz, weil die vom Browser berücksichtigte intrinsische Größe bei responsiven Bildern nicht schlicht mit der Dateibreite gleichgesetzt werden sollte.

const bild = document.querySelector("picture img");
await bild.decode();
console.table({
  quelle: bild.currentSrc,
  breiteImLayout: bild.getBoundingClientRect().width,
  pixeldichte: window.devicePixelRatio
});

Die Konsolenprüfung setzt eine erfolgreich ladbare Bilddatei voraus. Falls decode fehlschlägt, untersuche zuerst Status, Dateiformat und Inhalt. Ein vom Browser nicht dargestelltes Bild lässt sich nicht durch eine größere CSS-Breite reparieren. Für wiederholbare Vergleiche sind neue Seitenkontexte oder bewusst kontrollierte Cachebedingungen sinnvoll.

Ausschnittwechsel ist eine eigene Entscheidung

Die Auflösungsvarianten des Beispiels zeigen dasselbe Motiv. Bei einer echten Bildstrecke kann eine schmale Ansicht einen anderen Ausschnitt benötigen. Ein breites Gruppenbild mit winzigem Hauptmotiv wird durch eine kleinere Datei nicht verständlicher. Plane dann einen inhaltlich geeigneten Ausschnitt und ordne ihn mit passenden Bedingungen zu, statt lediglich die Pixelzahl zu reduzieren.

Kontrolliere jeden Ausschnitt auf abgeschnittene Gesichter, wichtige Produktdetails und Beschriftungen. Wenn die schmale Fassung etwas anderes zeigt, muss auch die gemeinsame Textalternative weiterhin sinnvoll sein. Vermeide Varianten, deren zentrale Aussage je nach Bildschirm wechselt. Die Technik sollte eine verständliche Darstellung desselben Inhalts unterstützen, nicht zufällig unterschiedliche Informationen verteilen.

Ein vollständiger erklärender Screenshot benötigt häufig eine andere Behandlung als ein dekoratives Titelmotiv. Er darf unbeschnitten bleiben und bei Bedarf eine lesbare Detailansicht anbieten. Eine rein randfüllende Darstellung ist hier kein Qualitätsziel, wenn sie wichtige Schaltflächen oder Nachweise entfernt.

Ladeverhalten und Bildgewicht gemeinsam betrachten

Ein direkt sichtbares Hauptbild sollte nicht durch unpassendes Lazy Loading künstlich spät angefordert werden. Weiter unten liegende Bilder können dagegen oft verzögert geladen werden. Der passende Zeitpunkt hängt von ihrer Rolle ab. web.dev erläutert diese Priorisierung und die Unterscheidung zwischen Ladezeitpunkt und Priorität.

Im Beispiel erhält das direkt sichtbare Bild eine hohe Priorität als Hinweis an den Browser. Diese Kennzeichnung ist kein garantierter erster Platz in der Netzwerkreihenfolge. Würde jedes Bild denselben Vorrang erhalten, ließe sich das tatsächlich wichtige Motiv weniger klar hervorheben. Auch decoding mit dem Wert async ist kein Ersatz für die Entscheidung über Lazy Loading.

Beurteile die gesamte Bildstrecke. Zwölf jeweils vernünftig optimierte Bilder können zusammen immer noch zu viel für den ersten Seitenaufruf sein. Eine Übersichtsseite braucht möglicherweise weniger gleichzeitig geladene Vorschaubilder oder eine andere Informationshierarchie. Die technische Optimierung sollte diese redaktionelle Entscheidung nicht verdecken.

Qualität an wichtigen Details abnehmen

Vergleiche Exporte bei der vorgesehenen Darstellung und zusätzlich an kritischen Details. Achte auf Schriftkanten, Konturen, Farbverläufe, Haut und feine Oberflächen. Ein ruhiger Hintergrund kann hervorragend komprimierbar sein, während ein anderes Motiv bei derselben Einstellung sichtbar leidet. Eine automatische Dateigrößengrenze ersetzt diese Abnahme nicht.

Für wiederkehrende Arbeit hilft eine kleine Auswahl unterschiedlicher Prüfvorlagen. Dazu gehören ein detailreiches Foto, ein dunkles Motiv mit Verläufen, eine transparente Kante und eine sachliche Erklärungsgrafik. Diese Motive bilden keine vollständige Qualitätsmessung. Sie machen jedoch sichtbar, ob eine geänderte Exportregel nur für einen bequemen Sonderfall gut aussieht.

Das hier verwendete Lernmotiv prüft Auswahl und Geometrie. Es wurde nicht zur Ermittlung eines besten Fotoformats eingesetzt. Die gespeicherten Dateigrößen gelten nur für diese Dateien und Einstellungen. Daraus werden ausdrücklich keine pauschalen Prozentwerte für andere Webseiten oder Bildbestände abgeleitet.

Textalternative und Auffindbarkeit erhalten

Kompression darf die Bedeutung eines Bildes nicht aus der Seite entfernen. Ein informatives Motiv braucht eine passende Beschreibung im jeweiligen Kontext. Eine dekorative Grafik kann eine leere Textalternative erhalten. Ein komplexes Diagramm benötigt gegebenenfalls eine zusätzliche Erklärung im Seitentext. Der Entscheidungsbaum der W3C WAI hilft bei dieser Einordnung.

Für Suchmaschinen bleiben eine sinnvolle Einbettung, zugängliche Bildadressen und ein verständlicher Kontext relevant. Die Google-Dokumentation zu Bild-SEO empfiehlt insbesondere reguläre HTML-Bildelemente und eine nutzbare src-Rückfalladresse. Aus einem bestimmten Format oder Dateinamen folgt keine garantierte Platzierung.

Beschreibe das tatsächliche Motiv statt eine Liste gewünschter Suchbegriffe einzufügen. Ein guter Alternativtext für eine technische Abbildung erklärt ihren Beitrag zur Seite. Er muss nicht zusätzlich die gesamte Bildunterschrift oder den Artikeltitel wiederholen. Ladegeschwindigkeit, Verständlichkeit und korrekte inhaltliche Einordnung ergänzen sich hier.

Export und Prüfung als gemeinsamen Ablauf pflegen

Ein automatisierter Export sollte Bildquelle, Ausgabegrößen, Format, Einstellungen und erzeugte Dateipfade nachvollziehbar verbinden. Ein kleines Manifest mit Abmessungen und Prüfsummen hilft dabei, versehentlich vermischte Versionen zu erkennen. Die web.dev-Anleitung zur Automatisierung behandelt die gemeinsame Erzeugung der Dateien und des zugehörigen Markups.

Leite das HTML möglichst aus derselben Variantendefinition ab. Dann entstehen weniger widersprüchliche Listen. Ein Prüfschritt kann sicherstellen, dass jede angegebene Breite zur Datei passt und jeder veröffentlichte Pfad erreichbar ist. Eine zusätzliche Browserprüfung kontrolliert, ob die Komponente ihre geplanten Bildbereiche tatsächlich einhält.

• Die Bildrolle und ihr wichtigster Ausschnitt sind festgelegt.
• Die Ausgangsdatei ist geeignet und bleibt als Quelle erhalten.
• Die Varianten entsprechen den tatsächlichen Darstellungsbreiten.
• Format, Dateiendung und Inhaltstyp stimmen überein.
• Breitenbeschreibungen und sizes passen zu Dateien und CSS.
• Direkt sichtbare Hauptbilder und spätere Bilder laden angemessen.
• Alle Kandidatenadressen wurden vollständig bereitgestellt und geprüft.
• Wichtige Details bleiben bei der vorgesehenen Darstellung lesbar.
• Textalternativen und Bildunterschriften erklären den tatsächlichen Inhalt.
• Eine Layoutänderung löst auch eine Prüfung der Bildauslieferung aus.

Mit einer Komponente anfangen

Wähle zunächst einen häufig verwendeten Bildbereich aus und messe ihn in den relevanten Ansichten. Erzeuge dafür passende Varianten, prüfe die Auswahl im Browser und kontrolliere die sichtbare Qualität. Erst danach wird die geprüfte Regel auf weitere gleichartige Komponenten übertragen. Unterschiedliche Aufgaben dürfen dabei unterschiedliche Ausschnitte und Exportregeln behalten.

Der verlässliche Fortschritt entsteht durch diese Verbindung aus Gestaltung, Dateien und tatsächlicher Darstellung. Eine kleine Datei ist hilfreich, wenn sie den benötigten Inhalt liefert. Eine vollständige Variantenliste ist hilfreich, wenn sie zum Layout passt. Der Browserversuch zeigt, ob diese Annahmen im konkreten Beispiel zusammenkommen. Die laufende Qualitätskontrolle sichert anschließend, dass neue Motive und spätere Layoutänderungen dieselbe Sorgfalt erhalten.