Cumulative Layout Shift vermeiden: So bleibt das Layout stabil

Von Manuel Hack, ihp media · Aktualisiert am 21. Juni 2026

Was ein Layout-Shift ist und warum er zählt

Sie wollen auf einen Link klicken. Im letzten Moment schiebt sich ein Banner von oben in die Seite, und Sie treffen die falsche Schaltfläche. Das ist ein Cumulative Layout Shift, kurz CLS, und genau dieses Erlebnis misst die gleichnamige Metrik.

CLS ist kein theoretischer Wert, sondern ein Maß für echten Ärger. Ein Element, das nach dem ersten Rendern seine Position ändert, ohne dass der Nutzer scrollt oder etwas eingibt, zählt als Layout-Shift. Passiert das mitten in einer Nutzerinteraktion, wird aus Ärger ein Fehler: ein unbeabsichtigter Kauf, ein falsches Formular abgeschickt, ein Button, der genau dann verspringt, wenn jemand ihn trifft.

Google wertet CLS seit 2021 als offizielles Core Web Vital. Der Wert fließt in die Gesamtbewertung der Seitenerfahrung ein, die wiederum ein Signal für das Ranking ist. Aber auch ohne Ranking-Ambitionen gilt: Seiten, die beim Laden springen, verlieren Nutzer. In einem Projekt, bei dem ein Cookie-Banner oberhalb der Hauptnavigation eingeblendet wurde, stieg die Absprungrate in den ersten zwei Sekunden messbar an, bis der Banner auf eine feste Mindesthöhe umgestellt wurde.

Wer die technischen Grundlagen der Core Web Vitals noch nicht kennt, liest am besten zuerst den Artikel Core Web Vitals einfach erklärt. Dieser Artikel hier konzentriert sich ausschließlich auf CLS: die Ursachen, die Lösungen und die Punkte, an denen die Umsetzung häufig scheitert.

Schwellenwerte und Messung

Der CLS-Wert ist keine Zeitangabe in Sekunden, sondern eine dimensionslose Zahl. Sie ergibt sich aus zwei Faktoren: dem Anteil des sichtbaren Bildschirms, den ein verschobenes Element einnimmt (Impact Fraction), multipliziert mit der zurückgelegten Verschiebedistanz im Verhältnis zur Bildschirmhöhe (Distance Fraction). Ein Element, das 50 Prozent des Bildschirms ausfüllt und um 10 Prozent der Bildschirmhöhe springt, erzeugt einen Wert von 0,05 für dieses einzelne Ereignis.

Seit Juni 2021 berechnet Google CLS nicht mehr als Summe aller Verschiebungen über die gesamte Sitzung, sondern in sogenannten Sitzungsfenstern. Ein Fenster fasst Verschiebungen zusammen, die weniger als eine Sekunde auseinanderliegen, und ist auf fünf Sekunden begrenzt. Gewertet wird das Fenster mit dem höchsten Wert. Das verhindert, dass Seiten mit langen Scrollpfaden durch viele kleine Verschiebungen unverhältnismäßig hohe Werte ansammeln. Die genaue Formel und Hintergründe zur Berechnung beschreibt web.dev/articles/cls.

Gemessen wird CLS über Google Search Console (Feldwerte), Lighthouse (Laborwert) und die Chrome DevTools im Performance-Tab. Wichtig: Ein guter Lighthouse-Wert schließt schlechte Feldwerte nicht aus. Personalisierte Inhalte, A/B-Tests und Drittanbieter-Skripte laden im Labor oft gar nicht. Die Search Console zeigt, was echte Nutzer erleben, und dieser Wert ist für das Ranking relevant.

Bilder und Videos ohne Abmessungen

Browser haben seit jeher ein Größenproblem mit Bildern: Ohne bekannte Abmessungen wissen sie nicht, wie viel Platz sie reservieren sollen. Bis HTML4 und in vielen CMS-Themes noch heute werden Bilder ohne explizite width– und height-Attribute eingebettet. Der Browser rendert den Folgeinhalt sofort unter dem noch nicht geladenen Bild, und wenn das Bild dann seine tatsächliche Höhe mitbringt, springt alles darunter nach unten.

Die Lösung ist dieselbe wie vor 25 Jahren, sie wirkt aber heute anders: Wenn width und height gesetzt sind, kann der Browser das Seitenverhältnis (aspect-ratio) berechnen und die passende Höhe reservieren, noch bevor eine einzige Bildzeile geladen ist. Das funktioniert auch bei responsiven Bildern, die per CSS mit max-width: 100% skaliert werden. Der Browser kennt das Verhältnis und passt die Höhe proportional an.

Für Videos gilt dasselbe. Ein video-Element ohne Abmessungen verhält sich exakt wie ein Bild ohne Attribute. Eingebettete Videos über iframe, also YouTube, Vimeo oder ähnliche Dienste, haben zusätzlich das Problem, dass der Browser die innere Größe erst nach dem Laden des Iframes kennt. Hier hilft aspect-ratio am Container, dazu mehr im Abschnitt weiter unten.

WordPress setzt width und height bei Bildern, die über die Mediathek eingebunden werden, automatisch. Problematisch sind Bilder, die direkt per HTML in Templates oder per Page-Builder-Module eingebunden werden und dabei die Attribute verlieren. Beim Optimieren von Webbildern sollte das Setzen der Abmessungen zur festen Routine gehören.

Web-Fonts und der Schriftwechsel

Web-Fonts sind aus zwei Gründen ein CLS-Risiko. Erstens dauert das Laden, besonders wenn die Datei von einem fremden Server kommt. Zweitens sind Schriften unterschiedlich breit: eine Bold-Schrift mit enger Laufweite und viel Kerning füllt eine Zeile ganz anders aus als die generische Fallback-Schrift, die der Browser bis dahin zeigt.

Zwei Szenarien entstehen beim Laden von Webfonts:

• FOUT (Flash of Unstyled Text): Der Browser zeigt erst Text in der Fallback-Schrift, dann wechselt er auf die Webfont. Der Wechsel kann das Layout verschieben, wenn sich Zeilenlängen ändern.
• FOIT (Flash of Invisible Text): Der Browser blendet Text aus, bis die Webfont geladen ist. Das vermeidet den Schriftwechsel, macht aber Text für eine kurze Zeit unsichtbar und schadet dem LCP.

font-display: swap in der @font-face-Deklaration wählt FOUT: Text ist sofort sichtbar, der Wechsel erfolgt sichtbar. Das ist in der Regel besser für den Largest Contentful Paint, kann aber CLS verursachen, wenn sich die Zeilenumbrüche beim Schriftwechsel stark verschieben. MDN dokumentiert alle Werte von font-display mit ihren Auswirkungen.

Zwei weitere Maßnahmen reduzieren den Schriftwechsel selbst. Erstens: <link rel="preload"> für die wichtigsten Schriftdateien direkt im <head>. Das gibt dem Browser den Auftrag, die Schrift frühzeitig anzufordern, noch bevor sie im CSS gefunden wird. Zweitens: Schriften lokal hosten statt von Google Fonts oder ähnlichen CDNs laden. Jede externe Schriftquelle erfordert einen DNS-Lookup und TCP-Handshake zu einer fremden Domain. Lokal gehostete Schriften laden aus derselben Verbindung wie der Rest der Seite, typischerweise deutlich schneller.

Seit Chrome 92 gibt es zusätzlich die CSS-Eigenschaft size-adjust im @font-face-Block. Sie skaliert die Fallback-Schrift so, dass ihre Zeichenbreite möglichst genau der Webfont entspricht. Ist der Schriftwechsel metrisch nahezu identisch, entsteht kein sichtbarer Layout-Shift. Das ist besonders nützlich, wenn eine Schrift sich nicht lokal hosten lässt.

Dynamische Inhalte, Ads und Banner

Cookie-Banner, Chat-Widgets, Werbeblöcke und Empfehlungsmodule haben eine Gemeinsamkeit: Sie kommen zu spät. Der Browser hat die Seite längst gerendert, wenn das JavaScript dieser Elemente ausgeführt wird. Erscheint dann ein Element mit unbekannter Höhe, schiebt es alles darunter nach unten.

Banner oberhalb des sichtbaren Bereichs sind besonders schädlich. Ein Cookie-Banner, der oben in die Seite springt, drückt die komplette Seite nach unten und erzeugt damit den maximalen Impact-Fraction-Wert. Ein solches Ereignis allein kann einen CLS-Wert von 0,15 und mehr erzeugen (Berechnungsgrundlage: web.dev/articles/cls).

Die sauberste Lösung: Den Platz im Layout von Anfang an reservieren. Ein Container mit fester Mindesthöhe oder einer festen Höhe hält den Platz frei, auch wenn der Inhalt noch nicht geladen ist. Der Inhalt füllt den Platz dann ohne Verschiebung auf. Für Banner mit variabler Inhaltshöhe gilt: lieber zu viel Platz reservieren als zu wenig. Ein kleiner Leerraum stört weniger als ein springendes Layout.

Für Werbeanzeigen gilt dasselbe Prinzip. Wenn ein Ad-Slot eine feste Mindesthöhe hat, die dem häufigsten Anzeigenformat entspricht, bleibt das Layout stabil. Das Google Publisher Tag unterstützt seit einiger Zeit reservierten Platz direkt über die Slot-Konfiguration.

Eingebettete Inhalte wie Social-Media-Posts, Karten oder iframes verhalten sich ähnlich: Ohne definierte Höhe nimmt der Browser zunächst null an. Wenn der eingebettete Inhalt seine eigentliche Größe liefert, springt der umliegende Inhalt. Hier hilft ein Wrapper-Container mit aspect-ratio, wie im nächsten Abschnitt beschrieben.

Was viele übersehen: Auch Interaktionen können CLS auslösen. Öffnet ein Nutzer ein Akkordeon-Menü oder einen Filterbereich, entsteht durch das Einblenden neuer Inhalte technisch ein Layout-Shift. Google rechnet allerdings Verschiebungen heraus, die innerhalb von 500 Millisekunden nach einer direkten Nutzereingabe (Klick, Tastatur, Tippen) auftreten. Scrollen gilt dabei nicht als solche Eingabe, also sollte auch das Nachladen von Inhalten beim Scrollen möglichst ohne Verschiebungen passieren.

CSS aspect-ratio als universelle Lösung

CSS aspect-ratio ist die sauberste Lösung für alle Fälle, in denen Elemente keine festen Pixelabmessungen haben, aber ein bekanntes Seitenverhältnis. Videos sind fast immer 16:9. Quadratische Thumbnails sind 1:1. Hochformat-Bilder auf Mobilseiten könnten 3:4 sein. Für jeden dieser Fälle reicht eine einzige CSS-Zeile, um den Platz exakt zu reservieren.

Vor aspect-ratio war das Padding-Hack die verbreitete Lösung: Ein Container bekommt padding-bottom: 56.25% (56,25 ist 100 / 16 * 9) und position: relative, das eingebettete Element wird absolut positioniert und füllt den Container aus. Das funktionierte, war aber schwer lesbar und fehleranfällig. aspect-ratio, das der W3C in der CSS Sizing Level 4 Spezifikation definiert, ersetzt diesen Hack vollständig.

Die Eigenschaft funktioniert auch für Bilder, die ohne feste width/height-Attribute auskommen müssen, etwa weil sie dynamisch generiert werden oder aus einem CMS ohne konsistente Metadaten kommen. aspect-ratio hält den Platz proportional frei, unabhängig von der Containerbreite. Das macht sie besonders wertvoll für responsive Layouts.

Ursachen, Symptome und Lösungen im Überblick

Code-Beispiele

Bilder mit width/height-Attributen

Das ist die wichtigste Einzelmaßnahme und in fast jedem CMS direkt umsetzbar.

<!-- Vorher: Browser reserviert keinen Platz -->
<img src="produkt.jpg" alt="Produktfoto Laufschuhe">

<!-- Nachher: Browser berechnet aspect-ratio und reserviert Höhe -->
<img src="produkt.jpg" width="800" height="600" alt="Produktfoto Laufschuhe">

Mit CSS max-width: 100%; height: auto; skaliert das Bild responsiv, behält aber das reservierte Seitenverhältnis bei. Die width/height-Attribute geben dem Browser nur das Verhältnis, nicht die finale Pixelgröße.

Videos und Embeds mit aspect-ratio

/* Container für 16:9-Video oder YouTube-iframe */
.video-wrapper {
  aspect-ratio: 16 / 9;
  width: 100%;
}

.video-wrapper iframe,
.video-wrapper video {
  width: 100%;
  height: 100%;
}

<!-- YouTube-Embed ohne Layout-Shift -->
<div class="video-wrapper">
  <iframe src="https://www.youtube.com/embed/VIDEO_ID"
    title="Beschreibung des Videos"
    frameborder="0" allowfullscreen></iframe>
</div>

Web-Fonts: preload und size-adjust

<!-- Im head: frühzeitig laden -->
<link rel="preload" as="font" type="font/woff2"
  href="/fonts/meine-schrift.woff2" crossorigin>

/* In der CSS: Schrift + Fallback angleichen */
@font-face {
  font-family: 'MeineSchrift';
  src: url('/fonts/meine-schrift.woff2') format('woff2');
  font-display: swap;
}

@font-face {
  font-family: 'MeineSchrift-Fallback';
  src: local('Arial');
  size-adjust: 105%; /* Fallback-Schrift auf Webfont-Breite skalieren */
  ascent-override: 90%;
}

body {
  font-family: 'MeineSchrift', 'MeineSchrift-Fallback', sans-serif;
}

Cookie-Banner mit reserviertem Platz

/* Platz reservieren, bevor der Banner erscheint */
.cookie-banner-slot {
  min-height: 80px; /* Mindesthöhe des Banners */
  width: 100%;
}

/* Banner füllt den reservierten Slot */
.cookie-banner {
  position: static; /* Kein absolute/fixed, das den Slot sprengt */
  width: 100%;
}

Animationen ohne Layout-Shift

/* Falsch: löst Layout-Reflow und CLS aus */
.element-einblenden {
  animation: slide-in 0.3s ease;
}
@keyframes slide-in {
  from { margin-top: -50px; }
  to   { margin-top: 0; }
}

/* Richtig: transform verändert nur die Darstellung, nicht den Fluss */
.element-einblenden {
  animation: slide-in 0.3s ease;
}
@keyframes slide-in {
  from { transform: translateY(-50px); opacity: 0; }
  to   { transform: translateY(0);     opacity: 1; }
}

<img
  src="BILD.jpg"
  width="1200"
  height="800"
  alt="Beschreibung des Bildes"
  loading="lazy"
  style="max-width: 100%; height: auto;"
>

/* CSS einmalig ins Stylesheet oder <style>-Tag */
.cls-video-wrapper {
  aspect-ratio: 16 / 9;
  width: 100%;
}
.cls-video-wrapper iframe,
.cls-video-wrapper video {
  width: 100%;
  height: 100%;
  display: block;
}

<!-- HTML-Einbindung -->
<div class="cls-video-wrapper">
  <iframe
    src="https://www.youtube.com/embed/VIDEO_ID"
    title="BESCHREIBUNG DES VIDEOS"
    frameborder="0"
    allowfullscreen
  ></iframe>
</div>

Praxisbeispiel

Bei einem WooCommerce-Shop, den wir für einen mittelständischen Händler überarbeitet haben, zeigte die Search Console durchgängig CLS-Werte zwischen 0,18 und 0,22 auf Produktseiten. Der Lighthouse-Laborwert lag dagegen bei 0,04. Das deutliche Auseinanderfallen von Labor- und Feldwert ist ein klares Signal, dass Drittanbieter-Skripte beteiligt sind.

Die Ursachen lagen auf drei Ebenen. Erstens hatten die meisten Produktbilder keine width/height-Attribute, weil das Theme sie beim Einbinden abstreifte. Zweitens startete ein Live-Chat-Widget etwa zwei Sekunden nach dem ersten Rendern und schob die Produktbeschreibung nach oben. Drittens lud eine externe Bewertungs-App ihre Sternebewertungen per JavaScript nach und fügte sie ohne reservierten Platz über dem „In den Warenkorb“-Button ein.

Drei Korrekturen brachten den CLS auf 0,06:

• Template-Anpassung: width und height werden aus den WP-Attachment-Metadaten in jeden img-Tag geschrieben.
• Chat-Widget: Platzhalter-Div mit Mindesthöhe gesetzt, Widget erscheint in einem vorbereiteten Slot.
• Bewertungs-App: Container mit fester Höhe für die Sternebewertung, damit der Button nicht springt.

Das zeigt das typische Muster: CLS entsteht selten durch eine einzelne Ursache, sondern durch mehrere kleine Verschiebungen, die sich summieren. Wer die Search-Console-Daten nach Seitentyp aufschlüsselt, findet schnell, wo der Handlungsbedarf am größten ist.

Für Shops und Websites, bei denen Core Web Vitals Teil des Auftrags sind, führen wir im Rahmen unseres Website-Checks eine vollständige CLS-Analyse durch, inklusive Gegenüberstellung von Feld- und Laborwerten und priorisierter Maßnahmenlist.

• Alle img-Elemente haben width– und height-Attribute gesetzt.
• Video-Container und iframes haben aspect-ratio und width: 100%.
• Web-Fonts werden lokal gehostet oder per preload frühzeitig angefordert.
• font-display: swap ist in allen @font-face-Deklarationen gesetzt.
• Für kritische Schriften ist ein size-adjust-Fallback definiert.
• Cookie-Banner und Chat-Widgets laden in reservierte Platzhalter-Container.
• Kein Banner erscheint neu oberhalb des sichtbaren Inhalts nach dem ersten Rendern.
• Werbeblöcke haben eine Mindesthöhe, die dem häufigsten Anzeigenformat entspricht.
• Animationen verwenden transform und opacity, nicht top, margin oder height.
• Feld-CLS in der Search Console liegt unter 0,1 (75. Perzentil).
• Lighthouse-Laborwert und Feldwert wurden verglichen und Abweichungen erklärt.

Häufige Fragen

Warum habe ich einen guten Lighthouse-Wert, aber schlechten CLS in der Search Console?

Lighthouse ist ein Labortest mit einer Netzwerksimulation und einem einzigen Seitenaufruf ohne Nutzerkontext. Personalisierte Inhalte, A/B-Tests, Cookie-Banner nach Opt-in und Drittanbieter-Widgets laden im Labor oft gar nicht. Die Search Console zeigt aggregierte Feldwerte echter Chrome-Nutzer über 28 Tage. Schlechtere Feldwerte als Laborwerte sind fast immer ein Zeichen für Drittanbieter-Skripte oder personalisierte Inhalte, die nur im echten Betrieb auftreten.

Zählt ein Cookie-Banner als Layout-Shift?

Ja, wenn er nach dem ersten Rendern in die Seite eingefügt wird und dabei vorhandenen Inhalt verschiebt. Das gilt unabhängig davon, ob der Banner am oberen oder unteren Rand erscheint. Banner am unteren Rand verschieben weniger oder gar nichts, wenn sie über bestehenden Inhalt gelegt werden (fixed positioning). Banner, die oben in den Dokumentfluss eingeschoben werden, sind die schädlichste Variante.

Muss ich für jedes Bild exakte Pixelwerte kennen?

Nein. Dem Browser genügt das Verhältnis. Wenn ein Bild nativ 1200 x 800 Pixel ist, sind width="1200" height="800" korrekt, auch wenn das Bild per CSS auf 600 Pixel Breite skaliert wird. Der Browser berechnet daraus das Verhältnis 3:2 und reserviert die proportionale Höhe. Bei dynamisch generierten Bildern reicht auch width="3" height="2", sofern das Verhältnis stimmt.

Verbessert das Setzen von width/height auch den LCP?

Indirekt, ja. Wenn das Hero-Bild korrekte Abmessungen hat und per fetchpriority="high" priorisiert wird, kann der Browser es früher anfordern und rendern. Wer beides zusammen optimiert, verbessert in der Regel sowohl CLS als auch LCP gleichzeitig. Details zum LCP erklärt der Artikel Largest Contentful Paint verbessern.

Helfen Page-Builder wie Divi automatisch gegen CLS?

Nein, Page-Builder lösen das Problem nicht von sich aus. CLS entsteht durch konkrete Umsetzungsentscheidungen, nicht durch das System selbst. Ein Divi-Theme kann sehr gute CLS-Werte haben, wenn Bilder korrekte Attribute haben, Schriften lokal gehostet werden und Widgets in reservierte Container laden. Problematischer sind Plugins von Drittanbietern, die der Builder nicht kontrolliert. Wer eine langsame WordPress-Seite debuggt, findet CLS-Probleme fast immer in diesen externen Skripten.

Animationen mit JavaScript: Wie vermeide ich CLS?

Verschiebungen, die über CSS-Transformationen mit transform: translateY(), translateX() oder scale() erzeugt werden, zählen nicht als Layout-Shift, weil sie den Dokumentfluss nicht verändern. Nur Eigenschaften, die das Layout neu berechnen lassen, also top, left, margin, padding, width oder height, können CLS auslösen. Eine Einblendanimation von unten per translateY(-20px) ist problemlos. Dieselbe Animation per margin-top: -20px ist es nicht.