Cumulative Layout Shift: Ursachen systematisch finden und beheben

1. Was CLS misst und warum es für Nutzer spürbar ist

Cumulative Layout Shift berechnet sich aus zwei Faktoren, dem Impact-Fraction, also dem Anteil des sichtbaren Bereichs, der von einer Verschiebung betroffen ist, und dem Distance-Fraction, also der Distanz, um die sich Elemente relativ zur Viewport-Größe verschoben haben. Beide Werte werden für jeden einzelnen, unerwarteten Layout-Shift multipliziert und über die gesamte Lebensdauer der Seite aufsummiert, wobei Google für eine gute Nutzererfahrung einen Gesamtwert von 0.1 oder darunter als Zielwert definiert.

Der Grund, warum CLS trotz seiner technischen Berechnungsformel eine so große Nutzerrelevanz hat, liegt in der unmittelbaren, oft frustrierenden Erfahrung, die ein Layout-Shift auslöst: Ein Klick landet auf dem falschen Button, weil sich dieser im letzten Moment nach unten verschoben hat, oder die Leseposition in einem Artikel geht verloren, weil plötzlich ein Werbebanner den Text nach unten drückt. Diese Erfahrung ist unabhängig davon, wie schnell die Seite objektiv geladen hat, und genau deshalb bewertet Google CLS als eigenständige, gleichrangige Metrik neben LCP und INP.

2. Ursache eins: Bilder ohne Dimensionsangabe

Die mit Abstand häufigste CLS-Ursache sind img-Elemente ohne explizit gesetzte width- und height-Attribute oder ein entsprechendes aspect-ratio in CSS. Ohne diese Angaben reserviert der Browser beim ersten Rendern keinen Platz für das Bild, da er dessen tatsächliche Größe erst kennt, sobald die Bilddatei vollständig heruntergeladen und dekodiert wurde. Sobald das Bild dann eintrifft, springt der gesamte darunterliegende Content abrupt nach unten, um dem nun bekannten Platzbedarf des Bildes Raum zu geben.

Die Lösung ist technisch simpel, wird in der Praxis aber trotzdem häufig übersehen, insbesondere bei dynamisch aus einem CMS oder einer API geladenen Bildlisten, bei denen die ursprünglichen Bilddimensionen nicht konsequent mit ausgeliefert werden. Das folgende Beispiel zeigt sowohl die klassische Lösung über width und height, deren Verhältnis der Browser automatisch als aspect-ratio interpretiert, als auch eine explizite CSS-Variante für Fälle, in denen die Dimensionen erst zur Laufzeit bekannt sind.

<!-- Klassische Loesung: width/height reservieren automatisch den Platz -->
<img
  src="/images/blog-artikel-header.avif"
  width="1200"
  height="630"
  alt="Artikel-Header"
  loading="lazy"
/>

<!-- CSS-Variante fuer dynamisch geladene Bilder ohne bekannte Dimensionen -->
<style>
  .produkt-bild-container {
    aspect-ratio: 4 / 3;
    background: var(--bild-placeholder-color, #e5e5e5);
  }
  .produkt-bild-container img {
    width: 100%;
    height: 100%;
    object-fit: cover;
  }
</style>

3. Ursache zwei: spät ladende Werbebanner ohne reservierten Platz

Werbebanner, die erst nach dem initialen Seitenaufbau durch ein asynchron geladenes Werbe-Skript eingefügt werden, gehören zu den hartnäckigsten CLS-Ursachen, da ihre finale Größe häufig erst nach dem Laden der eigentlichen Anzeige feststeht und der umgebende Content bis dahin keinen reservierten Platz dafür hat. Besonders problematisch sind Werbeplätze oberhalb des Hauptinhalts, etwa direkt unter der Kopfzeile, da eine dort auftretende Verschiebung praktisch den gesamten sichtbaren Bereich der Seite gleichzeitig betrifft und dementsprechend einen hohen Impact-Fraction-Wert erzeugt.

Die zuverlässigste Gegenmaßnahme ist, für jeden Werbeplatz einen festen Container mit einer Mindesthöhe zu reservieren, die der häufigsten oder größten zu erwartenden Anzeigengröße entspricht, selbst wenn die tatsächliche Anzeige kleiner ausfällt und dadurch temporär Leerraum entsteht. Dieser bewusst in Kauf genommene Leerraum ist in aller Regel das kleinere Übel gegenüber einem spürbaren Layout-Shift, da leerer, aber stabiler Raum von Nutzern kaum wahrgenommen wird, während ein abrupter Sprung des gesamten Seiteninhalts unmittelbar auffällt.

4. Ursache drei: Web-Font-Swap und FOUT

Web-Font-Swap entsteht, wenn eine Seite zunächst mit einer Systemschrift rendert und die eigentliche Webfont erst nachträglich austauscht, sobald deren Datei heruntergeladen wurde, ein Verhalten, das durch die font-display-Eigenschaft in CSS gesteuert wird. Bei font-display: swap wird sofort mit der Fallback-Schrift gerendert und später ausgetauscht, was zwar die wahrgenommene Ladezeit des Textes verbessert, aber einen Layout-Shift auslösen kann, wenn die Fallback-Schrift und die Webfont unterschiedliche Zeichenbreiten haben und dadurch Zeilenumbrüche und die Gesamthöhe von Textblöcken sich beim Austausch verändern.

Die wirksamste Gegenmaßnahme ist, eine Fallback-Schrift zu wählen, deren Metriken, also Zeichenbreite, x-Höhe und Zeilenabstand, der eigentlichen Webfont möglichst nahekommen, statt eine beliebige Systemschrift zu verwenden. Tools zur automatischen Erzeugung metrik-angepasster Fallback-Schriften berechnen dafür per @font-face size-adjust, ascent-override und descent-override-Werte, die die Fallback-Schrift so weit an die Zielschrift anpassen, dass der Austausch beim Font-Swap keinen oder nur einen minimalen Layout-Shift mehr verursacht.

5. Ursache vier: dynamisch eingefügter Content über bestehendem Content

Dynamisch eingefügter Content über bereits vorhandenem Content ist die vierte große CLS-Ursache und tritt typischerweise auf, wenn eine Consent-Banner-Bibliothek, eine Benachrichtigung oder ein spät geladenes Widget oberhalb des bereits sichtbaren Haupt-Contents eingefügt wird, statt als Overlay über dem Content zu erscheinen. Da der neue Content den vorhandenen Platz beansprucht, verschiebt sich alles darunter Liegende nach unten, oft genau in dem Moment, in dem der Nutzer bereits zu lesen begonnen hat.

Der grundlegende Unterschied zu den vorherigen drei Ursachen ist, dass dieses Problem meist nicht durch fehlende Größenreservierung entsteht, sondern durch eine grundsätzlich falsche Positionierungsstrategie: Elemente, die temporär oder asynchron erscheinen und keinen dauerhaften Platz im Content-Fluss beanspruchen sollen, gehören als position: fixed oder position: absolute außerhalb des normalen Dokumentenflusses platziert, damit ihr Erscheinen den umgebenden Content nicht verschiebt, sondern ihn optisch überlagert.

6. Debugging mit der Layout-Instability-API

Die Layout-Instability-API stellt über den PerformanceObserver Zugriff auf jedes einzelne Layout-Shift-Ereignis zur Laufzeit bereit, inklusive der betroffenen Elemente, der genauen Distance- und Impact-Fraction-Werte sowie eines Zeitstempels. Damit lässt sich pro Nutzer-Session genau nachvollziehen, welches Element wann und wie stark verschoben wurde, was für die Fehlersuche deutlich präziser ist als eine reine Gesamtwert-Messung, die nur die Summe aller Shifts zeigt, aber keine Aussage darüber trifft, welches einzelne Element den größten Anteil daran hat.

In Produktionsumgebungen lässt sich dieser Observer dauerhaft aktivieren und die gesammelten Daten an ein Monitoring-System senden, sodass CLS-Regressionen nach einem Deployment nicht erst durch eine manuelle Stichprobe auffallen, sondern automatisch mit dem konkreten, verursachenden Element gemeldet werden. Entscheidend ist dabei, nur Shifts ohne recente Nutzerinteraktion gemäß dem hadRecentInput-Flag der API in die CLS-Berechnung einzubeziehen, da vom Nutzer selbst ausgelöste Layoutänderungen, etwa durch das Aufklappen eines Akkordeons, nicht als negative Erfahrung zählen.

7. Layout-Shift-Regionen visuell in den DevTools identifizieren

Neben der programmatischen Erfassung über die Layout-Instability-API bieten die Chrome-DevTools im Performance-Panel eine visuelle Darstellung jedes einzelnen Layout-Shifts als farbig markierten Bereich in der Rendering-Zeitleiste, der genau zeigt, welcher Teil der Seite zu welchem Zeitpunkt betroffen war. Ein Klick auf das entsprechende Layout-Shift-Ereignis in der Zeitleiste hebt zusätzlich das konkrete DOM-Element im Elements-Panel hervor, wodurch sich die Ursache oft innerhalb weniger Sekunden auf ein einzelnes, konkretes Element eingrenzen lässt, statt den gesamten Seitenaufbau manuell durchsuchen zu müssen.

Ergänzend zeigt die Lighthouse-Auswertung unter dem Diagnostics-Abschnitt explizit die Elemente mit dem größten Beitrag zum Gesamt-CLS-Wert, sortiert nach ihrem jeweiligen Anteil, was bei Seiten mit mehreren gleichzeitig auftretenden Ursachen hilft, die Reihenfolge der Behebung nach tatsächlichem Impact statt nach subjektiver Vermutung zu priorisieren. Für wiederkehrende Regressionstests lässt sich derselbe Lighthouse-Report zudem automatisiert in eine CI-Pipeline einbinden, um neue CLS-Verursacher schon vor dem Deployment zu erkennen.

8. Layout-Shifts nach Impact-Fraction und Distance-Fraction bewerten

Nicht jeder gemessene Layout-Shift verdient dieselbe Aufmerksamkeit, da die Formel aus Impact-Fraction und Distance-Fraction für unterschiedliche Ursachen sehr unterschiedliche Beiträge zum Gesamtwert liefert. Ein kleines Icon, das sich um wenige Pixel verschiebt, erzeugt einen verschwindend geringen Beitrag, während ein Werbebanner, der den gesamten sichtbaren Bereich um mehrere hundert Pixel nach unten schiebt, den CLS-Wert einer Seite allein dominieren kann. Die Priorisierung der Behebung sollte sich deshalb konsequent am tatsächlichen, gemessenen Beitrag jedes einzelnen Elements orientieren, nicht an der gefühlten Wichtigkeit des betroffenen Bereichs.

In der Praxis bedeutet das, die von der Layout-Instability-API oder Lighthouse gelieferte, nach Beitrag sortierte Liste als direkte Arbeitsliste zu verwenden und sich zuerst um die zwei bis drei Elemente mit dem höchsten Anteil zu kümmern, bevor kleinere Verschiebungen überhaupt betrachtet werden. Diese Vorgehensweise führt in aller Regel deutlich schneller zu einem CLS-Wert unter dem Zielwert von 0.1 als eine Behebung in der Reihenfolge, in der die Ursachen im Code zufällig entdeckt werden.

9. Präventive Maßnahmen im Entwicklungsprozess verankern

Die nachhaltigste Lösung für CLS ist, die vier häufigen Ursachen bereits im Entwicklungsprozess strukturell zu verhindern, statt sie nachträglich in Produktion zu debuggen. Ein Linting-Regelwerk, das img-Elemente ohne width- und height-Attribute markiert, eine verbindliche Vorgabe für reservierte Werbeplatz-Container und ein projektweiter Standard für metrik-angepasste Fallback-Schriften reduzieren die Zahl der neu eingeführten CLS-Probleme bereits vor dem Code-Review deutlich.

Ergänzend sollte ein CLS-Budget als fester Bestandteil der CI-Pipeline etabliert werden, das einen Build fehlschlagen lässt, sobald ein Lighthouse-Lauf auf zentralen Seitentypen einen definierten Schwellenwert überschreitet. Diese Kombination aus präventiven Regeln während der Entwicklung und einer automatisierten Kontrolle vor jedem Deployment verhindert zuverlässig, dass CLS-Regressionen überhaupt erst live gehen, statt sie erst im Nachhinein über Real User Monitoring zu entdecken.

10. Zusammenfassung

11. FAQ: CLS-Ursachen finden: Das Wichtigste auf einen Blick