Was ist der Cumulative Layout Shift (CLS) und wie du ihn behebst

Was ist der Cumulative Layout Shift (CLS)?

Der Cumulative Layout Shift (CLS) steht bei den Core Web Vitals für den Bereich „visuelle Stabilität“. Der CLS misst, wie sich die Seite bewegt, während Inhalte rendern oder neu erscheinen. Du bemerkst das, wenn du beim Lesen die Textstelle verlierst. Oder wenn du auf den falschen Button klickst, weil er sich unter deinem Finger wegbewegt hat. Manche nennen die Metrik „Content Layout Shift“, aber ihr offizieller Name ist Cumulative Layout Shift.

Was ist ein guter Wert beim Cumulative Layout Shift (CLS)?

Ein guter CLS-Wert liegt zwischen 0 und 0,1. Zwischen 0,1 und 0,25 ist er verbesserungsbedürftig. Alles über 0,25 gilt als schlecht. Um die Core Web Vitals beim Cumulative Layout Shift zu bestehen, müssen mindestens 75 % deiner Seitenaufrufe einen „guten“ CLS-Wert erreichen. Das ist das p75 deiner Field Data, mobil und auf dem Desktop separat gemessen. Der CLS hat keine Einheit: Er ist ein Score, während LCP und INP Zeitangaben sind.

Der Core-Web-Vitals-Bericht in der Google Search Console gruppiert fehlerhafte URLs nach Problemen. „CLS-Problem: mehr als 0,1 (Mobilgeräte)“ bedeutet verbesserungsbedürftig. „CLS-Problem: mehr als 0,25 (Desktop)“ heißt schlecht. Beide Schwellenwerte gelten für jeden Gerätetyp. Die Search Console mittelt deine Field Data über ein rollierendes Zeitfenster. Ein Fix färbt den Bericht also nicht an dem Tag grün, an dem er live geht: Über Wochen hinweg zeigt er teilweise noch den alten Stand der Website.

Was dich ein Layout Shift kostet

Eine Seite, die herumspringt, fühlt sich kaputt an – selbst wenn alles darauf funktioniert.

• Besucher und deine Marke: Ein Shift unterbricht den Besucher bei dem, was er gerade tut. Er verliert die Zeile, die er gerade liest, oder tippt auf den falschen Link. Manche geben auf und verlassen die Seite. Eine Website, die sich ständig bewegt, wirkt zudem schlecht gebaut – und das fällt auf das Unternehmen dahinter zurück.
• Barrierefreiheit: Layout Shifts treffen Nutzer am härtesten, die nur einen Teil der Seite sehen – etwa beim Heranzoomen oder mit einer Bildschirmlupe. Ein einziger Shift kann den Text, den du gerade liest, komplett aus dem Sichtfeld schieben.
• SEO und Such-Ranking: Googles Ranking-Systeme nutzen die Core Web Vitals, und der CLS ist einer davon. Er ist ein kleiner Faktor. Google betont, dass die relevantesten Inhalte immer zuerst angezeigt werden. Eine gute Page Experience hilft, wenn viele Seiten ähnlich relevant sind.

Wie wird der CLS gemessen?

Browser melden Layout Shifts über die Layout Instability API. Füge diesen Code in die Konsole ein, und jeder Shift wird geloggt:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Jeder Eintrag hat einen value – den Score dieses Shifts – und eine sources-Liste mit den verschobenen Elementen. Bei Shifts direkt nach einem Klick steht hadRecentInput auf true. Sie werden hier zwar geloggt, zählen aber nicht zum CLS.

So wird der CLS berechnet

Jeder Layout Shift bekommt einen eigenen Score:

layout shift score = impact fraction * distance fraction

Die Impact Fraction beschreibt, wie viel vom Viewport die verschobenen Elemente einnehmen – gezählt wird die Fläche vor und nach dem Shift. Die Distance Fraction zeigt, wie weit sie sich bewegt haben, als Anteil der größten Abmessung des Viewports (auf dem Smartphone ist das die Höhe).

Nimm ein Element, das die Hälfte des Viewports einnimmt und sich um 25 % der Viewport-Höhe nach unten verschiebt. Vorher und nachher zusammen deckt es 75 % des Viewports ab. Das ergibt eine Impact Fraction von 0,75 und eine Distance Fraction von 0,25. Der Shift erzielt also 0,75 * 0,25 = 0,1875. Schon ein einziger solcher Shift liegt über 0,1. Der CLS der gesamten Seite addiert diese Shift-Werte pro Session-Fenster auf – mehr dazu unten.

Erwartete vs. unerwartete Layout Shifts

Wenn du auf einen Link wie „Mehr laden“ klickst, erwartest du, dass neue Inhalte erscheinen und sich die Seite bewegt. Deshalb zählen nur unerwartete Layout Shifts für den CLS. Jeder Shift innerhalb von 500 Millisekunden nach einem Klick, Tippen oder Tastendruck wird aus der Berechnung herausgenommen. Ein Dropdown-Menü, das sich per Klick öffnet, kostet dich also nichts. Scrollen zählt nicht als Eingabe – mehr dazu unten.

Layout-Shift-Sessions

Als der CLS eingeführt wurde, zählte er jeden Shift über die gesamte Lebensdauer der Seite zusammen. Seiten, die lange offen bleiben – wie Infinite Scroller oder Single-Page-Apps –, häuften endlos Punkte an. Seit Juni 2021 wird der CLS in Sessions berechnet. Jede Session dauert maximal 5 Sekunden und endet nach einer Lücke von 1 Sekunde zwischen zwei Layout Shifts. Die Session mit dem höchsten CLS-Wert bestimmt den finalen CLS-Score.

Angenommen, die erste Session summiert sich auf 0,095, die nächste auf 0,15 und die letzte auf 0. Der finale CLS-Score ist der höchste der drei Werte: 0,15.

Häufige Ursachen für CLS

Jeder Layout Shift funktioniert nach demselben Prinzip. Nachdem die Seite gerendert ist, wird ein Element größer, kleiner oder ändert seine Position. Alles danach im Layout verschiebt sich mit. Das sind die typischen Ursachen:

Bilder, Videos und Iframes ohne Größenangaben

Medien ohne Größenangaben gehören zu den häufigsten Ursachen für CLS. Der Browser erfährt die Größe eines Bildes erst, wenn die ersten Bytes der Datei ankommen. Fehlen bis dahin width und height (oder ein CSS-aspect-ratio), reserviert er keinen Platz und das Bild hat keine Höhe. Sobald es lädt, rutscht alles darunter nach unten.

Wie Bilder und Medien Layout Shifts verursachen behandelt Bilder, Videos und Iframes ohne Größenangaben, die CSS-Falle mit width: auto, Art Direction, responsive Bilder, Lazy Loading und Platzhalterbilder.

Webfont-Swaps

Während der Webfont lädt, zeigt die Seite ihren Text in einer Fallback-Schriftart an. Trifft der Webfont ein, formatiert sich der Text neu. Andere Buchstabenbreiten und Zeilenhöhen führen zu neuen Zeilenumbrüchen. Jeder Block unter diesem Absatz verschiebt sich.

Der Lighthouse-Audit „Ensure text remains visible during webfont load“ drängt zu font-display: swap. Für den CLS bringt das allein nichts: Der Text erscheint zwar schneller in der Fallback-Schrift, aber der Swap verschiebt ihn trotzdem. Was das Problem behebt: Ein Fallback, der denselben Platz einnimmt – über @font-face-Metrik-Overrides wie size-adjust und ascent-override. Liefere die Schriftart außerdem schneller aus, indem du sie selbst hostest und kritische Fonts vorab lädst. Den Code dazu liefert der Leitfaden zum Finden und Beheben.

CSS-Animationen und -Transitions

Animierst du top, left, width oder height, berechnet der Browser das Layout in jedem Frame neu. Jeder dieser Frames kann ein Layout Shift sein. transform und opacity lösen niemals ein Layout aus – bewege Elemente also stattdessen damit. Layout Shifts durch CSS-Transitions zeigt dir die Lösung Schritt für Schritt.

Werbung, Embeds und dynamisch eingefügte Inhalte

Werbung lädt spät und schiebt Inhalte nach unten. Ein Cookie-Banner, der sich über die Seite legt, verschiebt nichts. Wird er jedoch oben eingefügt, drückt er die gesamte Seite nach unten. AJAX-Requests bewirken dasselbe, wenn sie Inhalte ohne reservierten Platz einfügen. Jedes Mal landet etwas auf der Seite, von dem der Browser beim ersten Layouten nichts wusste. Reserviere den Platz vorab, etwa mit min-height auf dem Container. Bei Drittanbieter-Embeds wie YouTube und Google Maps beseitigt das Facade-Pattern den CLS komplett.

Durch Scrollen ausgelöste Layout Shifts

Ein Page-Load-Test in Lighthouse scrollt nicht – diese CLS-Ursache findet er also nicht. Header, die sich beim Scrollen ausblenden, Parallax-Effekte und schrumpfende Navigationsleisten animieren oft top oder height. Scrollen gilt in der Spezifikation zur Layout Instability nicht als ausschließende Eingabe. Jeder dadurch ausgelöste Layout Shift zählt also voll in deinen CLS-Score. Nutze transform: translateY() für alles, was sich beim Scrollen bewegt. Die Details findest du in Wie scroll-getriggerte Animationen CLS verursachen.

CLS-Probleme finden und beheben

Starte mit Field Data. Ein Lab-Test sieht nur die ersten Sekunden eines Seitenaufrufs. Deine Besucher scrollen jedoch, warten auf Ads und lesen weiter. Prüfe das p75 des CLS für Mobilgeräte und Desktop separat: Beim CLS schneidet der Desktop oft schlechter ab. Die Google Search Console zeigt, welche Gruppen von Seiten durchfallen. Ein RUM-Tool wie CoreDash erfasst außerdem das konkret verschobene Element. So erkennst du direkt, ob es das Produktbild auf einem Template oder der Ad-Slot auf einem anderen ist. Achte auch auf den Verlauf: Ein plötzlicher Sprung bedeutet meistens, dass ein Release etwas hinzugefügt hat – etwa einen neuen Banner oder einen Werbeslot.

Reproduziere das Problem anschließend in den Chrome DevTools oder mit der Extension Core Web Vitals Visualizer und finde heraus, was die Bewegung auslöst. Die Schritt-für-Schritt-Diagnose, Anleitungen für Tools, Code-Fixes für jede Ursache und eine Checkliste für schnelle Lösungen findest du in Probleme mit dem Cumulative Layout Shift (CLS) finden und beheben.

Fallstudie: Der Core-Web-Vitals-A/B-Test von Rakuten 24

Rakuten 24, ein japanischer Onlineshop, hat eine stark frequentierte Landingpage für die Core Web Vitals optimiert. Sie ließen die Variante einen Monat lang gegen das Original laufen – mit jeweils 50 % des Traffics pro Version. Für den CLS reservierten sie Platz für Bilder per CSS-aspect-ratio und für Lazy-Loading-Elemente mit min-height. Der CLS der optimierten Seite sank um 92,72 %. Im mobilen Ladetest lud sie zudem 0,4 Sekunden schneller, mit besseren Werten bei FCP und TTFB. Im Vergleich zum Original erzielte die optimierte Seite:

• 53,37 % mehr Umsatz pro Besucher
• 33,13 % höhere Conversion-Rate
• 15,20 % höherer durchschnittlicher Bestellwert
• 35,12 % niedrigere Ausstiegsrate

Der CLS zeigte die größte Verbesserung im Test, aber auch Ladezeit, FCP und TTFB wurden besser. Diese Ergebnisse gehen also auf das Konto der gesamten Optimierung. Nimm sie nicht als Beleg dafür, was der CLS allein wert ist.

Was reale CLS-Daten zeigen

Im Chrome UX Report vom August 2026 erzielten 81,5 % aller Origins einen guten CLS – verglichen mit 80,1 % im August 2025.

Auf corewebvitals.io selbst misst CoreDash den CLS als den stärksten Core Web Vital. 92,8 % aller Page Loads schneiden mit „gut“ ab, fast ohne Unterschied zwischen Desktop (92,8 % gut) und Mobilgeräten (92,7 % gut). Beide haben ein p75 von 0. Bei mindestens drei Vierteln aller Seitenaufrufe gab es also überhaupt keinen Layout Shift.

Im gesamten Web schneidet der CLS mobil besser ab als auf dem Desktop. Das ist genau das Gegenteil von LCP und INP. Der Web Almanac 2025 liefert die Zahlen dazu und zeigt, wie oft die oben genannten Ursachen auftreten:

• 81 % der mobilen Websites und 72 % der Desktop-Websites haben einen guten CLS. Rund 9 % der mobilen und 10 % der Desktop-Websites schneiden schlecht ab.
• 62 % der mobilen Seiten haben mindestens ein Bild ohne explizite Größenangaben – 2024 waren es noch 66 %.
• 40 % der mobilen Seiten (44 % auf dem Desktop) nutzen Animationen ohne Compositing.
• 87 % der mobilen Seiten nutzen mindestens einen Webfont, und etwa 12 % laden einen vorab (Fonts-Kapitel).

Weiterführende Leitfäden

Diese Guides gehen bei der Suche und Behebung von CLS tiefer ins Detail:

• CLS-Probleme finden und beheben: Schritt-für-Schritt-Diagnose mit Tool-Anleitungen, Code-Fixes für jede Ursache und einer Quick-Fix-Checkliste.
• Wie Bilder und Medien Layout Shifts verursachen: CLS durch Bilder, Videos und Iframes ohne Größenangaben, Art Direction, responsive Bilder, Lazy Loading und Platzhalter.
• Layout Shifts durch Bilder mit automatischer Größenanpassung beheben: Richtige Maße für Bilder und responsive Container vergeben.
• Layout Shifts durch CSS-Transitions beheben: Layout-auslösende CSS-Animationen finden und durch Compositor-basierte Alternativen ersetzen.
• Scroll-getriggerte Animationen und CLS: Die CLS-Ursache, die ein Lighthouse-Ladetest übersieht – und wie du sie behebst.
• Google Fonts selbst hosten: Weniger CLS beim Laden von Schriftarten durch Self-Hosting, passendes font-display und Preloading.
• Text beim Laden von Webfonts sichtbar halten: font-display und Font-Metrik-Overrides gegen Layout Shifts beim Font-Swap.
• Ein Chat-Widget mit perfekten Core Web Vitals bauen: Eine Fallstudie zur Integration eines Drittanbieter-Widgets ohne Regressionen bei CLS, INP oder LCP.

Die Core-Web-Vitals-Übersicht deckt alle drei Metriken ab, und die Core-Web-Vitals-Checkliste hilft dir beim Audit deiner Website.