Sprachen

Responsive Bilder (srcset)

So liefern Sie responsive Bilder mit den Attributen srcset und sizes sowie dem picture-Element aus, wann Sie welche Methode verwenden und wie responsive Bilder LCP und CLS beheben, ohne ein direktes Ranking-Signal zu sein.

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 21. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Responsive Bilder ermöglichen es dem Browser (über srcset + sizes) oder dem Autor (über <picture>), das passend dimensionierte Bild pro Gerät auszuliefern. srcset/sizes ist Auflösungswechsel (gleiches Bild, Browser wählt – ein Vorschlag); <picture> ist Art Direction oder Formatwechsel (vom Autor festgelegte Ausschnitte/Formate – ein Befehl). Die meisten Websites benötigen nur srcset/sizes. Dies ist kein direktes Ranking-Signal und ändert nicht, was Google indexiert – Google indexiert die src-URL –, aber es ist die konkrete Lösung, die Lighthouse für überdimensionierte Bilder empfiehlt (sein Audit „Properly size images“ schlägt bei einer Lücke von 4 KiB fehl) und, gepaart mit expliziten width/height-Attributen, verhindert es CLS. Behalten Sie den Alt-Text identisch und die Bild-URLs über alle Breakpoints stabil für Mobile-First-Indexierung. Ich verwende das exakte srcset- und width/height-Muster aus meinem Ahrefs-CLS-Artikel. Dies ist unter dem Image-SEO-Hub verschachtelt.

TL;DR – Zwei Aufgaben, eine Syntaxfamilie. srcset/sizes auf <img> = Auflösungsumschaltung (gleiches Bild, Browser wählt die beste Passung – ein Vorschlag); <picture> = Art Direction oder Formatumschaltung (vom Autor festgelegte Ausschnitte/Formate – ein Befehl). Die meisten Websites benötigen nur das Erste. Responsive Bilder sind kein direktes Ranking-Signal und ändern nicht, was Google indexiert – Google indexiert die src-URL, also behalten Sie alt-Text, Dateinamen und Bild-URLs über alle Breakpoints hinweg stabil (Mobile-First-Indexierung). Der eigentliche Nutzen sind die Core Web Vitals: Passend dimensionierte Bilder sind die Lösung für den Lighthouse-Audit „Properly size images“ (schlägt bei einer Lücke von 4 KiB fehl), und width/height (oder aspect-ratio) – nicht srcset – verhindert CLS. Versehen Sie das LCP-Bild nicht mit Lazy Loading. Ich verwende das exakte srcset- + width/height-Muster aus meinem Ahrefs-CLS-Artikel erneut.

Evidence for this claim The HTML responsive-image features srcset, sizes, and picture let browsers select an appropriate image candidate. Scope: Current HTML responsive image behavior. Confidence: high · Verified: WHATWG HTML: Responsive images Evidence for this claim Google can process responsive images and recommends src as a fallback while using srcset or picture for responsive delivery. Scope: Current Google Images responsive-image guidance. Confidence: high · Verified: Google Search Central: Responsive images

Zwei verschiedene Aufgaben, eine Syntaxfamilie

Alles in diesem Thema lässt sich auf zwei Mechanismen reduzieren, und ein Großteil der Verwirrung entsteht dadurch, dass beide miteinander vermischt werden:

  1. Auflösungsumschaltung – dasselbe Bild in verschiedenen Größen oder Pixeldichten. Sie geben dem Browser ein Menü mit srcset und sizes auf dem <img>-Element, und der Browser entscheidet, welche Datei anhand von Viewport und Bildschirmdichte geladen wird. Das ist der häufigste Fall.
  2. Art Direction – ein wirklich anderes Bild pro Bedingung: ein breiter Ausschnitt auf dem Desktop, ein enger vertikaler Ausschnitt auf dem Smartphone oder ein völlig anderes Dateiformat. Hier bestimmen Sie die Wahl mit dem <picture>-Element.

Der Kurs web.dev Learn: Responsive Bilder formuliert den Unterschied genau richtig: Mit srcset erhält der Browser Vorschläge, während “the picture element gives commands.” (Übersetzung) „das picture-Element Befehle erteilt“. Quelle Auch der entscheidende Merksatz stammt von web.dev: “You probably won’t need to use the picture element for most of your responsive images — the srcset and sizes attributes on the img element cover a lot of use cases.” (Übersetzung) „Sie werden das picture-Element für die meisten Ihrer responsiven Bilder wahrscheinlich nicht benötigen – die srcset- und sizes-Attribute auf dem img-Element decken viele Anwendungsfälle ab.“ Greifen Sie nur dann zu <picture>, wenn Sie tatsächlich ein anderes Bild benötigen, nicht eine andere Größe desselben Bildes.

srcset und sizes – Auflösungsumschaltung

w-Deskriptoren vs. x-Deskriptoren

srcset akzeptiert eine durch Kommas getrennte Liste von Kandidatendateien, die jeweils mit einem Deskriptor gekennzeichnet sind. Es gibt zwei Arten:

  • Breiten-Deskriptoren (w) – Sie geben die intrinsische Pixelbreite jeder Datei an (puppy-2000.jpg 2000w). Der Browser kombiniert das mit Ihrem sizes-Wert, um herauszufinden, welche Datei am besten zum Platz und zur Pixeldichte des Geräts passt. Das ist die flexible Variante, die Sie am häufigsten verwenden werden.
  • Pixeldichte-Deskriptoren (x) – Sie geben an, welche Datei für welches Gerätepixelverhältnis gedacht ist (logo.png 1x, logo@2x.png 2x). Verwenden Sie diese für Bilder mit fester Größe (ein Avatar, ein Logo), bei denen sich die angezeigte Größe nie ändert; Sie benötigen sizes bei x-Deskriptoren nicht.

Faustregel: fließende, inhaltsbreite Bilder → w-Deskriptoren + sizes; Bilder mit fester Größe in der UI → x-Deskriptoren.

Warum sizes wichtig ist (und was passiert, wenn Sie es weglassen)

Bei w-Deskriptoren ist sizes keine optionale Kosmetik – es ist die Art und Weise, wie der Browser weiß, wie groß das Bild gerendert wird, damit er vor dem Layout wählen kann. Laut web.dev erklärt: “tells the browser what size you expect the image to be displayed at under different conditions,” (Übersetzung) „teilt dem Browser mit, in welcher Größe das Bild unter verschiedenen Bedingungen voraussichtlich angezeigt wird“ als eine durch Kommas getrennte Liste von Medienbedingungen und Breiten:

sizes="(max-width: 600px) 480px, 1000px"

Lesen Sie es so: „Wenn der Viewport 600px oder schmaler ist, wird das Bild etwa 480px breit sein; andernfalls etwa 1000px.“ Lassen Sie sizes weg und der Browser nimmt an, dass das Bild die volle Viewport-Breite (100vw) ausfüllt – auf einem breiten Bildschirm kann er also Ihre größte Datei für ein Bild laden, das tatsächlich nur 400px breit dargestellt wird, und damit den ganzen Zweck zunichtemachen. Fehlendes sizes ist der häufigste srcset-Fehler überhaupt.

Leiten Sie diese Breitenwerte nicht bloß aus Ihrer Vorstellung des Layouts ab – prüfen Sie die tatsächliche gerenderte CSS-Breite des Bildes im Browser (DevTools → Elemente → die berechnete Breite des <img>-Elements) an jedem relevanten Breakpoint und setzen Sie sizes entsprechend. Ein sizes-Wert, der nicht der tatsächlichen gerenderten Breite entspricht, führt weiterhin dazu, dass der Browser den falschen Kandidaten auswählt, auch wenn das Markup syntaktisch korrekt ist – Syntaxvalidierung allein fängt das nicht ab; siehe den currentSrc-Check unten, um zu bestätigen, was tatsächlich geladen wurde.

Praxisbeispiel (mein wiederverwendbares Muster)

Das ist das genaue Muster aus meinem Ahrefs-Artikel, What Is Cumulative Layout Shift (CLS) & How To Improve It, erweitert um sizes:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Jedes Element ist tragend: src ist der Fallback und die URL, die Google indexiert; srcset listet die Kandidaten mit w-Deskriptoren auf; sizes teilt dem Browser die gerenderte Breite mit; width/height reservieren Platz (der CLS-Fix – mehr dazu unten); alt bleibt identisch, egal welche Datei geladen wird.

Das picture-Element – Art Direction und Formatwechsel

Wann Sie es tatsächlich brauchen

Verwenden Sie <picture> für zwei Dinge, die srcset nicht kann:

  1. Art Direction – ein anderer Bildausschnitt pro Breakpoint. Das Beispiel von web.dev: Auf einem schmalen Telefon könnten Sie einen hohen, engen Ausschnitt ausliefern; auf einem breiten Desktop einen kurzen, breiten. Gleiches Motiv, bewusst anderer Bildausschnitt.
  2. Formatwechsel – AVIF/WebP mit JPEG-Fallback über <source type="…"> anbieten, sodass der Browser das erste unterstützte Format nimmt. Das knüpft direkt an die Format-Empfehlungen im Image-SEO-Hub an.

Die Syntax (und die Fallback-Regel)

Das <picture>-Element umschließt ein oder mehrere <source>-Elemente und endet immer mit einem einfachen <img>:

<!-- Art direction: different crop per breakpoint -->
<picture>
  <source media="(max-width: 600px)" srcset="hero-crop-mobile.jpg">
  <img src="hero-crop-desktop.jpg" width="1200" height="675"
       alt="Product hero shot">
</picture>

<!-- Format switching: modern format with a fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="675" alt="Product hero shot">
</picture>

Dieses abschließende <img src> ist nicht optional. Google formuliert das ausdrücklich: Gemäß Abschnitt 4.8.1 des HTML-Standards: “make sure that you provide an img element as a fallback with a src attribute when using the picture element.” (Übersetzung) „Stellen Sie sicher, dass Sie ein img-Element als Fallback mit einem src-Attribut bereitstellen, wenn Sie das picture-Element verwenden.“ Es ist die Datei, auf die ältere Browser und Crawler zurückgreifen – und, nochmals, diejenige, die Google indexiert.

Hilft srcset bei SEO? Direkt vs. indirekt

Viele konkurrierende Leitfäden verfehlen die entscheidende Einordnung; deshalb formuliere ich sie deutlich.

Direkt: nein. Markup für responsive Bilder ist kein Ranking-Signal wie Alt-Text oder Dateinamen für die Bildersuche. Das Hinzufügen von srcset verbessert Ihre Positionen nicht, und es ändert nicht, was in Google Bilder erscheint. Google indexiert das Bild, auf das in src verwiesen wird; die srcset/<picture>-Varianten sind ein Auslieferungsmechanismus, keine separat indexierbaren Assets. Behalten Sie Ihren alt-Text, Dateinamen und strukturierte Daten an diesem primären src-Bild.

Indirekt: ja, und es ist einer der größten Hebel, die Sie haben. Richtig dimensionierte Bilder sind der effektivste konkrete Fix für zwei Core Web Vitals – LCP und CLS –, die in Googles Page-Experience-Signale einfließen. Das ist der ganze Nutzen. Es ist dieselbe Form wie die WebP/AVIF-Geschichte im Image-SEO-Hub: kein Boost für das Format selbst, der Gewinn ist Geschwindigkeit.

Responsive Bilder und LCP

Übergroße Bilder sind eine der häufigsten Ursachen für ein langsames Largest Contentful Paint, und responsive Bilder sind der von Lighthouse empfohlene Fix. Der Lighthouse-Audit „Properly size images“ nennt: “all images in your page that aren’t appropriately sized, along with the potential savings” (Übersetzung) „Alle Bilder auf Ihrer Seite, die nicht passend dimensioniert sind, einschließlich der möglichen Einsparungen.“ Alles, was größer als nötig ist, “just results in wasted bytes and slows down page load time.” (Übersetzung) „führt lediglich zu verschwendeten Bytes und verlangsamt das Laden der Seite“. Die wörtlich empfohlene Lösung lautet: “With responsive images, you generate multiple versions of each image, and then specify which version to use in your HTML or CSS using media queries, viewport dimensions, and so on.” (Übersetzung) „Bei responsiven Bildern erstellen Sie mehrere Versionen jedes Bildes und legen anschließend mithilfe von Media Queries, Viewport-Abmessungen und ähnlichen Mitteln fest, welche Version in Ihrem HTML oder CSS verwendet wird.“

Zwei Besonderheiten, die Sie kennen sollten:

  • Die Fehlerschwelle liegt bei 4 KiB. Lighthouse markiert ein Bild nur, wenn “the rendered size is at least 4 KiB smaller than the actual size.” (Übersetzung) „Die dargestellte Größe ist mindestens 4 KiB kleiner als die tatsächliche Größe.“ Kleine Überschreitungen zählen nicht; eine 3000px-Datei in einem 400px-Bereich auszuliefern, schon.
  • Eine Tooling-Abkürzung. Google empfiehlt RespImageLint, “a helpful bookmarklet for identifying the optimal srcset and sizes values for your images.” (Übersetzung) „ein hilfreiches Bookmarklet, mit dem sich die optimalen srcset- und sizes-Werte für Ihre Bilder ermitteln lassen“. Führen Sie es aus, bevor Sie Breakpoints manuell berechnen.

Verwenden Sie kein Lazy Loading für das LCP-Bild

Das ist die Regel, die am häufigsten missachtet wird. srcset auf Ihrem Hero ist in Ordnung – aber kombinieren Sie es niemals mit Lazy Loading auf dem LCP-Element. Das größte Bild im sofort sichtbaren Bereich sollte direkt mit fetchpriority="high" geladen werden, genau wie im Image-SEO-Hub beschrieben. Und wenn Sie ein responsives Hero-Bild mit <picture> erstellen, verwenden Sie weiterhin die native Wechsellogik: Google warnt, dass es “Inhalte, die Benutzerinteraktionen erfordern, nicht lädt” wie Wischen oder Klicken. Ein JavaScript-Verfahren, das reale Bilddateien erst nach einer Interaktion lädt, versteckt es also vor Google.

Responsive Bilder und CLS

Hier ist die Falle: srcset allein bewirkt nichts gegen Layout-Shift. Die Auflösungsumschaltung entscheidet, welche Datei geladen wird; sie reserviert keinen Platz dafür. Ohne Abmessungen gilt laut web.dev-Leitfaden zur CLS-Optimierung: “text shifts down the page as images load to make room for them” (Übersetzung) „Text verschiebt sich beim Laden der Bilder nach unten, um Platz für sie zu schaffen“, weil der Platz “can only be allocated once the browser begins downloading it and can determine its dimensions” (Übersetzung) „erst reserviert werden kann, sobald der Browser mit dem Herunterladen beginnt und die Abmessungen ermitteln kann“.

Die Lösung sind explizite Abmessungen, und das funktioniert mit responsivem Markup zusammen:

  • Setzen Sie width- und height-Attribute auf dem <img>. Moderne Browser “set the default aspect ratio of images based on an image’s width and height attributes” (Übersetzung) „legen das Standardseitenverhältnis von Bildern anhand der width- und height-Attribute eines Bildes fest“, sodass diese beiden Zahlen den richtigen Platz reservieren, bevor eine srcset-Variante heruntergeladen wird. (web.dev)
  • Kombinieren Sie diese Attribute mit height: auto in CSS für flexible Container. Das ist der Teil, der widersprüchlich aussieht, es aber nicht ist: web.dev empfiehlt, “use CSS to scale the image to the width of its container” (Übersetzung) „das Bild per CSS auf die Breite seines Containers zu skalieren“ und “set height: auto; to avoid a fixed value for the image height” (Übersetzung) „height: auto; zu setzen, um einen festen Wert für die Bildhöhe zu vermeiden“. Die HTML-Attribute legen das intrinsische Seitenverhältnis fest; das CSS lässt das Bild flexibel skalieren. Zusammen verhindern sie CLS und bleiben responsiv.
  • Oder verwenden Sie CSS aspect-ratio, um den Platz zu reservieren, wenn Sie keine Attribute setzen können.

Das widerlegt einen hartnäckigen Mythos: width-/height-Attribute brechen keine flexiblen Layouts. Attribute + height: auto ist die richtige Kombination, kein Konflikt. Ich erkläre die vollständige Mechanik des Layout-Shifts in meinem Ahrefs-CLS-Artikel; die Kurzfassung ist “reserve the space so that there’s no shift” (Übersetzung) „Reservieren Sie den Platz, damit keine Layoutverschiebung entsteht“; das Bild füllt ihn. Quelle

Auswirkungen auf Mobile-First-Indexierung

Google indexiert hauptsächlich die mobile Version Ihrer Seiten, daher gelten zwei Regeln mehr als früher, wenn Sie responsive Varianten ausliefern:

  • Halten Sie den Alt-Text über alle Breakpoints identisch. Googles “make sure that the mobile site has the same alt text for images as the desktop site.” (Übersetzung) „Stellen Sie sicher, dass die mobile Website denselben Alt-Text für Bilder verwendet wie die Desktop-Website.“ Quelle Ein art-directed mobiler Zuschnitt darf Kontext, den Google benötigt, nicht verlieren.
  • Halten Sie Bild-URLs stabil. “Don’t use URLs that change every time the page loads for images.” (Übersetzung) „Verwenden Sie für Bilder keine URLs, die sich bei jedem Laden der Seite ändern.“ Quelle Das passt zu Googles Image-SEO-Empfehlung, “consistently reference the image with the same URL” (Übersetzung) „das Bild durchgängig unter derselben URL zu referenzieren“ (Quelle), damit es gecacht und wiederverwendet werden kann. Responsive CDNs, die pro Anfrage eine neue URL erzeugen, brechen das – verwenden Sie stabile URLs für Ihre Varianten.

Googles eigene Zusammenfassung, warum sich das lohnt, ist klar: “designing responsive web pages leads to better user experience, since people can access them across a plethora of device types.” (Übersetzung) „Die Gestaltung responsiver Webseiten führt zu einer besseren Benutzererfahrung, da Menschen auf sie über eine Vielzahl von Gerätetypen zugreifen können.“ Quelle

Was ist mit Bing?

Es gibt keine Bing-spezifischen Richtlinien zu srcset, sizes oder dem <picture>-Element – Bings öffentliche Dokumentation behandelt responsives Bild-Markup überhaupt nicht. Begründen Sie den Einsatz responsiver Bilder daher nicht mit einem vermeintlichen Bing-Algorithmussignal; das Argument ist Performance und UX, was Bing (wie Google) als Seitenqualität behandelt und nicht als etwas, für das Sie eine dokumentierte Regel für responsive Bilder anführen könnten.

Häufige Fehler

  • sizes bei w-Deskriptoren vergessen – der Browser nimmt 100vw an und lädt möglicherweise Ihre größte Datei für einen kleinen Slot.
  • Den Fallback-src bei <picture> weglassen – ein Spec-Verstoß, den Google ausdrücklich anprangert, und es ist die URL, die Crawler indexieren.
  • Nicht übereinstimmendes width/height-Verhältnis im Vergleich zum tatsächlich ausgelieferten Bild – verursacht weiterhin Layout-Shift.
  • Lazy-Loading des LCP-Hero-Bilds – verzögert LCP ohne Grund; laden Sie es eagerly mit fetchpriority="high".
  • Bild-URLs pro Anfrage neu generieren – bricht Googles Caching und die Mobile-First-Regel für „stabile URLs“.
  • Zu <picture> greifen, wenn srcset/sizes ausreichen würden – unnötige Komplexität; web.dev sagt, die meisten Websites brauchen es nicht.

Wo dies einzuordnen ist

Dies ist die ausführliche Anleitung zu Größenanpassung und Auslieferung unter dem breiteren Image-SEO-Hub – die Performance-Hälfte der Bild-SEO, parallel dazu, wie der Alt-Text-Leitfaden die Bildsuch-Hälfte behandelt. Für die vollständige Mechanik des Layout-Shifts siehe meinen Ahrefs-CLS-Artikel; für LCP, fetchpriority und die Ladestrategie geht es um die Core Web Vitals aus der Perspektive der Bildoptimierung.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.