Wie Bilder und Medien Layout Shift verursachen (und wie man es behebt)

Wie Bilder und Medien Layout Shift verursachen (und wie man es behebt)

Der 2025 Web Almanac beziffert, was ich immer wieder in der Praxis sehe: 62 % der mobilen Seiten haben mindestens ein Bild ohne explizite width und height. Das macht Medien ohne Größenangabe zur Hauptursache für Cumulative Layout Shift im Web. Und jeder dieser Shifts ist mit Techniken vermeidbar, die es seit 2019 gibt.

Zuletzt überprüft von Arjen Karel im März 2026

Der Browser weiß nicht, wie groß Ihr Bild ist

Jeder Layout Shift durch Bilder lässt sich auf eine Sache zurückführen. Der Browser weiß nicht, wie viel Platz er reservieren soll, bevor das Bild geladen ist.

Wenn der Browser auf ein <img>-Tag ohne Dimensionen stößt, rendert er das Bild mit 0x0 Pixeln. Die Datei kommt an, der Browser berechnet das Layout neu, und alles unterhalb des Bildes springt nach unten. Dieser Sprung ist Ihr CLS.

Wie width und height Layout Shift verhindern

In den Jahren 2019 und 2020 haben alle großen Browser eine Funktion eingeführt, die die Funktionsweise der Attribute width und height verändert hat. Browser nutzen sie nun, um ein Seitenverhältnis zu berechnen, bevor das Bild heruntergeladen wird.

Wenn Sie dies schreiben:

<img src="hero.jpg" width="800" height="450" alt="Description">

Generiert der Browser intern dies:

img[Attributes Style] {
    aspect-ratio: auto 800 / 450;
}

Keine Bilddaten erforderlich. Der Browser kennt das Verhältnis und reserviert den vertikalen Platz.

Dieses interne Verhältnis hat die niedrigste CSS-Priorität, sodass jede von Ihnen geschriebene CSS-Regel es überschreibt. Das ist wichtig, weil es der Grund dafür ist, warum width: auto alles kaputt macht (mehr dazu gleich).

Das Schlüsselwort auto sagt dem Browser: Verwende dieses Verhältnis als Platzhalter, aber sobald das tatsächliche Bild geladen ist, wechsle zu den echten Dimensionen. Wenn Sie versehentlich falsche Werte festlegen (z. B. width="4" height="3" bei einem 16:9-Bild), reserviert der Browser zunächst 4:3-Platz und korrigiert dann auf 16:9, wenn das Bild geladen ist. Diese Korrektur ist ein Layout Shift. Verwenden Sie immer die tatsächlichen Pixeldimensionen.

Für responsive Bilder fügen Sie dieses CSS hinzu:

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

height: auto berechnet die Höhe aus dem Verhältnis. max-width: 100% verhindert, dass das Bild seinen Container überschreitet. Der Browser kennt die width und das Verhältnis. Das reicht aus.

Warum width:auto Ihren CLS ruiniert

Dies ist der Fehler, den ich am häufigsten sehe und der die meiste Zeit beim Debuggen verschwendet. Der Entwickler setzt width und height bei jedem Bild, macht alles im HTML richtig, lässt Lighthouse laufen, bekommt eine grüne Punktzahl, geht live. Dann kommen CLS-Beschwerden von echten Nutzern.

Die Ursache liegt immer irgendwo im CSS. Eine globale Regel macht alles zunichte:

<style>
img {
    width: auto;
    height: auto;
    max-width: 100%;
}
</style>

Das Problem ist width: auto. Da das interne Verhältnis des Browsers die niedrigste CSS-Priorität hat, überschreibt jede Regel es. width: auto entfernt die width, die der Browser zur Berechnung der height verwendet hat. Beide Dimensionen werden unbekannt. Das Bild wird mit 0x0 gerendert, bis die Datei heruntergeladen ist, und springt dann auf die volle Größe.

Das Festlegen von aspect-ratio in CSS behebt dies nicht. Mit width: auto behandelt der Browser die width als 0, bevor das Bild geladen wird. Ein Seitenverhältnis, das von 0 berechnet wird, ergibt immer noch 0. Null mal irgendwas ist null.

Hier ist der Teil, der dies so schwer zu finden macht: Es verursacht nur einen Shift für Erstbesucher. Wenn das Bild im Browser-Cache ist, sind die tatsächlichen Dimensionen sofort verfügbar und es tritt kein Shift auf. Sie als Entwickler werden es nie auf Ihrer eigenen Maschine sehen. Ihre Tester werden es nicht sehen. Ihr QA-Team wird es nicht sehen. Nur Ihre echten Nutzer sehen es bei ihrem ersten Besuch, und das ist genau der Besuch, den Google für CrUX misst.

Ich habe Stunden in Calls mit Engineering-Teams verbracht, die schworen, ihr CLS sei behoben, weil sie es lokal nicht reproduzieren konnten. Es war immer dies. Überprüfen Sie Ihr CSS. Wenn Sie ein globales width: auto auf Bildern haben, ist das Ihr Problem.

Die Lösung:

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

Entfernen Sie width: auto. Behalten Sie height: auto und max-width: 100%. Dies ist das von web.dev empfohlene Pattern.

Schnelltest: Klicken Sie mit der rechten Maustaste auf ein beliebiges Bild auf Ihrer Site, wählen Sie "Element untersuchen" und sehen Sie sich die berechneten Stile (computed styles) an. Wenn Sie width: auto sehen, wissen Sie jetzt, was zu tun ist. Für die vollständige Anleitung siehe Layout Shift durch Bilder mit automatischer Größenanpassung beheben.

Wann CSS aspect-ratio die bessere Wahl ist

Die Attribute Width/height sind der Standardansatz. Aber manchmal möchten Sie, dass CSS unabhängig vom Bildinhalt ein bestimmtes Verhältnis erzwingt. Ein Hero-Banner, das immer 16:9 sein muss, oder ein Produktkarten-Grid, bei dem jedes Bild die gleiche Form haben muss:

<style>
img {
    aspect-ratio: 16 / 9;
    width: 100%;
}
</style>

Funktioniert in allen modernen Browsern (Chrome 88+, Firefox 87+, Safari 15+) und auf jedem Element, nicht nur bei Bildern und Videos.

Für normale Content-Bilder sind width/height-Attribute besser. Sie beschreiben die tatsächlichen Dimensionen und korrigieren sich selbst, wenn das Bild geladen wird.

Sie können beides kombinieren:

<style>
img {
    aspect-ratio: auto 16 / 9;
    width: 100%;
}
</style>

Das Schlüsselwort auto bedeutet hier: Verwende 16/9, bevor das Bild geladen wird, wechsle nach dem Laden zum natürlichen Verhältnis. Platzreservierung vor dem Laden, genaue Größenbestimmung danach.

Videos haben das gleiche Problem

Ein Video ohne width und height wird mit 0x0 gerendert, until der Browser genug von der Datei heruntergeladen hat, um ihre Metadaten zu lesen. Bei einer langsamen Verbindung dauert das Sekunden. Die Lösung ist identisch zu Bildern:

<video src="demo.mp4" width="1280" height="720" autoplay muted loop></video>

Browser berechnen intern ein aspect-ratio: auto 1280 / 720 aus den Attributen. Fügen Sie height: auto; max-width: 100%; in CSS hinzu und Sie sind fertig.

Eine Sache, auf die Sie achten sollten: das Poster-Bild. Wenn Sie ein Poster festlegen, aber keine Dimensionen für das Video-Element angeben, passt sich das Element der Größe des Posters an. Wenn das Video zu spielen beginnt und eine andere Auflösung hat, erhalten Sie einen Shift. Stellen Sie width und height so ein, dass sie der Videoauflösung entsprechen, nicht der des Posters.

Iframes haben standardmäßig 300x150 Pixel

Ein Iframe ohne explizite Dimensionen hat standardmäßig 300x150 Pixel. Für die meisten Einbettungen (YouTube, Google Maps, Social Media Posts) ist das falsch. In dem Moment, in dem die Einbettung lädt und die Größe anpasst, verschiebt sich alles um sie herum.

Im Gegensatz zu Bildern berechnen Iframes nicht automatisch ein Seitenverhältnis aus ihren Attributen. Sie müssen die Größenbestimmung selbst vornehmen:

<style>
.responsive-iframe {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
}
</style>

Dies ersetzt den alten padding-top Hack, bei dem Sie das Iframe in einen Container mit padding-top: 56.25% gepackt und es absolut positioniert haben. Der alte Hack funktioniert immer noch. aspect-ratio ist sauberer und benötigt keinen Wrapper.

Oder laden Sie das Iframe überhaupt nicht

Für YouTube, Vimeo, Google Maps und Social Embeds habe ich vor Jahren aufgehört, Iframes beim Laden der Seite zu laden. Das Facade Pattern (Fassadenmuster) ist in jeder Hinsicht besser: Zeigen Sie ein statisches Platzhalterbild mit dem richtigen Seitenverhältnis. Wenn der Nutzer klickt, tauscht JavaScript es gegen das echte Iframe aus. Kein Iframe, kein CLS, keine verschwendeten Ressourcen.

Der Shift durch den Austausch passiert innerhalb von 500ms nach der Nutzereingabe und ist per Design vom CLS ausgeschlossen.

Für Implementierungsbeispiele siehe Perfekte YouTube Embeds und Google Maps ohne PageSpeed-Verlust.

Art Direction: wenn Mobile- und Desktop-Ausschnitte unterschiedliche Verhältnisse haben

Art Direction bedeutet, dass Sie bei unterschiedlichen Viewport-Breiten unterschiedliche Bildausschnitte ausliefern. Breites Querformat auf dem Desktop, engeres Hochformat auf mobilen Geräten. Das <picture>-Element regelt dies mit <source>-Elementen.

Das CLS-Problem: Diese Ausschnitte haben normalerweise unterschiedliche Seitenverhältnisse. Der Browser muss wissen, welche Dimensionen zu welchem Breakpoint gehören. Sie können width und height für jedes <source> festlegen:

<picture>
    <source
        media="(max-width: 799px)"
        srcset="hero-mobile.jpg"
        width="480" height="600">
    <source
        media="(min-width: 800px)"
        srcset="hero-desktop.jpg"
        width="1200" height="400">
    <img
        src="hero-desktop.jpg"
        width="1200" height="400"
        alt="Product hero image">
</picture>

Chrome und Safari übernehmen die korrekten width/height-Werte von der jeweils aktiven <source>. Firefox nicht. Es gibt einen Bug (Bug 1694741), bei dem Firefox immer die Fallback-Dimensionen des <img> verwendet, unabhängig von der ausgewählten Source. Wenn der mobile Ausschnitt ein anderes Verhältnis hat, zeigt Firefox einen Shift.

Wenn alle Ihre Ausschnitte das gleiche Verhältnis haben (nur unterschiedliche Auflösungen), spielt dieser Bug keine Rolle. Er tritt nur auf, wenn sich die Verhältnisse zwischen den Breakpoints unterscheiden.

Workaround für Firefox

Bis der Fix ausgeliefert wird, verwenden Sie CSS Media Queries, die den Breakpoints in Ihren <source>-Elementen entsprechen:

<style>
picture img {
    width: 100%;
    height: auto;
}
@media (max-width: 799px) {
    picture img {
        aspect-ratio: 480 / 600;
    }
}
@media (min-width: 800px) {
    picture img {
        aspect-ratio: 1200 / 400;
    }
}
</style>

Dies überschreibt das interne Verhältnis des Browsers mit explizitem CSS pro Breakpoint. Funktioniert in allen Browsern.

Behalten Sie das gleiche Verhältnis über alle srcset-Quellen hinweg bei

Responsive Bilder mit srcset und sizes können CLS verursachen, wenn die width/height-Attribute nicht mit der ausgewählten Quelle übereinstimmen. Die Regel ist einfach: Alle Bilder in einem srcset müssen das gleiche Seitenverhältnis haben. Wenn dies der Fall ist, reicht ein Satz von width/height auf dem <img> aus:

<img
    src="hero-800.jpg"
    srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, 800px"
    width="800" height="450"
    alt="Hero image">

800:450 ist das gleiche Verhältnis über alle drei Varianten hinweg. Egal, welche der Browser auswählt, der reservierte Platz ist korrekt.

Wenn Sie Verhältnisse im selben srcset mischen (eine Quelle mit 16:9, eine andere mit 4:3), wird der reservierte Platz für mindestens eines davon falsch sein. Tun Sie das nicht. Verwenden Sie stattdessen <picture> mit <source>-Elementen, wenn Sie unterschiedliche Verhältnisse benötigen.

Wenn sizes falsch ist

Das Attribut sizes teilt dem Browser mit, wie breit das Bild bei jeder Viewport-Größe gerendert wird. Wenn es nicht mit dem tatsächlichen CSS-Layout übereinstimmt, wählt der Browser eine Quelle, die zu groß oder zu klein ist. Das verursacht keinen CLS (das Verhältnis bleibt gleich), aber es verschwendet Bandbreite oder erzeugt ein unscharfes Bild.

sizes=auto für Lazy-Load-Bilder

Chrome 126+ und Edge 126+ unterstützen sizes="auto" bei per Lazy Loading geladenen Bildern. Der Browser berechnet die korrekte Größe aus dem CSS-Layout, anstatt sich auf Ihr manuell geschriebenes sizes-Attribut zu verlassen. Funktioniert nicht bei Eager-Load-Bildern, da der Browser die Layoutgröße benötigt, bevor CSS geparst wurde.

Laden Sie nicht Above-the-Fold per Lazy Loading

Das Lazy Loading von Bildern Above-the-Fold (im sofort sichtbaren Bereich) verursacht zwei Probleme gleichzeitig. Es verzögert den LCP, da loading="lazy" die Ressource vor dem Preload-Scanner verbirgt. Der Browser kann das Bild erst nach dem Layout entdecken. Und wenn dem Bild auch noch Dimensionen fehlen, erhalten Sie zusätzlich zur verzögerten Ladezeit einen Layout Shift.

Der 2025 Web Almanac berichtet, dass 16 % der Seiten ihr LCP-Bild immer noch per Lazy Loading laden. Das bedeutet, dass 16 % des Webs ihr wichtigstes Bild ohne jeden Nutzen verzögern.

loading="lazy" gehört auf Bilder außerhalb des initialen Viewports. Nirgendwo sonst.

1x1 Pixel Platzhalter verursachen massive Shifts

JavaScript Lazy Loading-Skripte verwenden oft ein winziges, transparentes 1x1 Pixel großes GIF als Platzhalter in src, während die echte URL in data-src liegt. Wenn IntersectionObserver auslöst, tauscht JavaScript sie aus.

Das verursacht CLS, weil der 1x1-Platzhalter 1px hoch gerendert wird. Wenn das 800x450-Bild lädt, springt das Element von 1px auf 450px. Wenn Sie im Jahr 2026 immer noch eine JavaScript Lazy Loading-Bibliothek verwenden, hören Sie damit auf. Das native loading="lazy" handhabt den Platzhalter intern und respektiert die width/height-Attribute. Es wird seit 2022 von allen Browsern vollständig unterstützt.

Wenn Sie einen bestimmten Grund haben, JavaScript Lazy Loading beizubehalten (Intersection-Schwellenwerte, Fade-in-Animationen), verwenden Sie einen Platzhalter mit demselben Seitenverhältnis wie das endgültige Bild. Ein transparentes 16x9 SVG anstelle von 1x1.

LQIP richtig gemacht

Ein verschwommener Thumbnail-Platzhalter sieht besser aus als leerer Raum. Der Schlüssel: Behalten Sie das Seitenverhältnis bei. Wenn Ihr endgültiges Bild 800x450 ist, sollte Ihr LQIP eine winzige Version (10x6 oder 20x11) mit dem gleichen Verhältnis sein. Skalieren Sie es mit CSS hoch, wenden Sie einen Blur-Filter an. Wenn das echte Bild lädt, ersetzt es die Unschärfe bei gleichen Dimensionen. Kein Shift.

Next.js macht dies automatisch. Die Image-Komponente generiert zur Build-Zeit width, height und blurDataURL. Null CLS.

Verwenden Sie object-fit für Container mit fester Größe

Produktkarten-Grids, bei denen jede Karte gleich hoch ist, die Bilder aber unterschiedliche Verhältnisse haben. Ich sehe dieses Pattern ständig:

<style>
.product-image {
    width: 100%;
    aspect-ratio: 1 / 1;
    object-fit: cover;
    object-position: center;
}
</style>
<img
    src="product.jpg"
    width="400" height="600"
    class="product-image"
    alt="Product name">

aspect-ratio: 1 / 1 erzwingt ein Quadrat. object-fit: cover füllt das Quadrat und schneidet den Überhang ab. Die Größe ist gesperrt, bevor das Bild lädt.

So ersetzen Sie auch CSS-Hintergrundbilder durch ordnungsgemäße <img>-Elemente. Hintergrundbilder können nicht per Lazy Loading geladen werden, können kein fetchpriority verwenden, und der Preload-Scanner findet sie nicht, bevor die CSS-Datei geparst ist. Ein <img> mit object-fit: cover bietet Ihnen alle Performance-Kontrollen, die einem Hintergrundbild fehlen.

Auto-playing Karussells erzeugen unendlich viel CLS

Folienübergänge, die left, width oder margin animieren, lösen eine Layout-Neuberechnung aus. Da Autoplay keine Nutzereingabe ist, zählt jeder Shift zum CLS. Ein Auto-playing Karussell mit Layout-auslösenden Übergängen kann auf unbestimmte Zeit CLS erzeugen.

Fixieren Sie die Container-Dimensionen mit einem festen Seitenverhältnis, animieren Sie mit transform: translateX() anstelle von left oder margin-left (Transforms laufen auf der GPU und lösen niemals ein Layout aus), und wenn Sie Autoplay verwenden müssen, dürfen sich die Dimensionen des Foliencontainers nicht ändern. Jede Größenänderung zählt als CLS.

In einem Karussell ohne Autoplay passieren die meisten Übergänge innerhalb von 500ms nach einem Nutzerklick und sind vom CLS ausgeschlossen. Autoplay hebt diesen Schutz auf. Der web.dev Karussell-Leitfaden behandelt die Implementierungsdetails.

SVG, Containment und andere Edge Cases

SVGs, die über <img> geladen werden, benötigen width und height auf dem Tag, genau wie Rasterbilder. Inline <svg>-Elemente benötigen explizite Dimensionen oder eine viewBox mit CSS aspect-ratio. Ein SVG ohne beides hat standardmäßig 300x150.

Für Einbettungen, die Sie nicht kontrollieren können (Werbeplätze, Widgets von Drittanbietern, nutzergenerierte Inhalte), verwenden Sie CSS Containment, um zu verhindern, dass sich der Shift ausbreitet:

<style>
.embed-container {
    min-height: 250px;
    contain: layout style;
}
</style>

contain: layout style sagt dem Browser, dass nichts innerhalb dieses Containers das Layout außerhalb beeinflusst. Die Einbettung kann sich verschieben, wachsen oder schrumpfen. Der Rest der Seite bleibt an Ort und Stelle.

Für Below-the-Fold Abschnitte mit vielen Medien überspringt content-visibility: auto mit contain-intrinsic-size das Layout für Inhalte, die nicht auf dem Bildschirm sind. Ohne contain-intrinsic-size hat das Element die Höhe null und die Ausdehnung, wenn der Nutzer dorthin scrollt, ist ein Layout Shift:

<style>
.below-fold-gallery {
    content-visibility: auto;
    contain-intrinsic-size: auto 500px;
}
</style>

Das Schlüsselwort auto bedeutet: Beginne mit 500px als Schätzwert, aber sobald der Browser es rendert und die echte Höhe kennt, merke dir diesen Wert.

So finden Sie Bild-CLS

Sie werden Bild-CLS auf Ihrer eigenen Maschine nicht finden. Ihr Browser-Cache hat bereits die Dimensionen. Sie benötigen Bedingungen für Erstbesucher oder RUM-Daten (Real User Monitoring).

Real User Monitoring

Beginnen Sie mit CoreDash oder einem anderen RUM-Tool. CLS-Attributionsdaten zeigen genau, welche Elemente sich verschoben haben. Navigieren Sie einfach zu CLS und sehen Sie sich die Attributions-Element-Tabelle an. Sie wird Ihnen genau sagen, welche Elemente sich verschoben haben. Um Bilder zu finden, filtern Sie einfach nach Image und Sie erhalten eine Tabelle aller Bildelemente, die von Layout Shifts betroffen sind, geordnet nach Auswirkung.

Chrome DevTools

Deaktivieren Sie den Cache im Network-Tab, drosseln Sie auf Slow 4G, aktivieren Sie Screenshots, laden Sie neu. Achten Sie auf visuelle Sprünge. Öffnen Sie dann das Performance-Panel und suchen Sie nach "Layout Shift"-Einträgen. Klicken Sie auf einen Shift, um den Node, den Score und ob es eine kürzliche Nutzereingabe gab, zu sehen.

Core Web Vitals Visualizer

Die Core Web Vitals Visualizer Erweiterung hebt jeden Layout Shift mit einem farbigen Overlay hervor. Ich verwende dies als meinen ersten Schritt, bevor ich das Performance-Panel öffne. Laden Sie mit aktiver Erweiterung neu und Sie sehen genau, was sich bewegt hat.

Lighthouse fängt einen Teil davon auf

Lighthouse markiert Bilder ohne width und height. Aber es übersieht das width: auto Problem komplett, da die HTML-Attribute vorhanden sind. CSS überschreibt sie, und Lighthouse überprüft keine berechneten Stile (computed styles). Deshalb vertraue ich niemals einem grünen Lighthouse CLS Score, ohne auch Felddaten zu überprüfen.

Schnelle Checkliste zur Fehlerbehebung

Wo das Web beim Bild-CLS steht

Die Zahlen aus dem 2025 Web Almanac:

• 62 % der mobilen Seiten haben mindestens ein Bild ohne Größenangabe. Ein Rückgang von 66 % im Jahr 2024. Immer noch die Mehrheit.
• 65 % der Desktop-Seiten haben Bilder ohne Größenangabe. Ein Rückgang von 69 %.
• Beim p75 hat eine Desktop-Seite 9 Bilder ohne Größenangabe. Mobile hat 8.
• Beim p90: 25 auf dem Desktop, 22 mobil.
• Mediane Höhe von Bildern ohne Größenangabe: 111px auf dem Desktop, 98px mobil. Genug, um einen Absatz zu verschieben.
• 72 % der Desktop- und 81 % der mobilen Origins bestehen den CLS. Ein Anstieg von 62 % im Jahr 2021.
• 40 % der mobilen Seiten verwenden immer noch nicht-kompositierte (non-composited) Animationen, die von sich aus CLS verursachen.

CLS hat sich in den letzten vier Jahren stärker verbessert als jeder andere Core Web Vital. Bilder ohne Größenangaben sind immer noch der größte Verursacher. Beheben Sie dieses eine Problem, und Layout Shifts verschwinden auf den meisten Sites.

Weiterführende Leitfäden

• Was ist Cumulative Layout Shift (CLS): Der vollständige Leitfaden. Formel, Schwellenwerte, Session Windows und alle CLS-Ursachen jenseits von Bildern.
• CLS-Probleme finden und beheben: Schritt-für-Schritt-Diagnose mit RUM-Daten, DevTools und Lösungen für jede Ursache.
• Layout Shift durch Bilder mit automatischer Größenanpassung beheben: Der vollständige width: auto Walkthrough.
• Bilder für Core Web Vitals optimieren: Preloading, responsive Bilder, Formate, Priorisierung.
• Layout Shift durch CSS Transitions: Wie Layout-auslösende Animationen CLS verursachen.
• Perfekte YouTube Embeds: Das Facade Pattern für null CLS.
• Google Maps 100% PageSpeed: Der gleiche Facade-Ansatz für Maps.