Kumulative Layoutverschiebung (CLS)

TL;DR — Cumulative Layout Shift (CLS) misst, wie stark sich Inhalte auf einer Seite unerwartet bewegen, während du sie liest oder antippst – etwa wenn ein spät geladenes Bild den Text nach unten schiebt oder ein Button kurz vor dem Klick springt. Der Wert beginnt bei 0; 0,1 oder weniger ist gut. Meist entsteht CLS, weil Elemente vor dem Laden keinen Platz reserviert haben.

Was CLS ist

Du kennst das vielleicht, auch wenn du den Begriff noch nie gehört hast. Du liest einen Artikel, eine Anzeige oder ein Bild wird oberhalb deiner aktuellen Position fertig geladen, und plötzlich springt die ganze Seite nach unten. Oder du willst auf „Abbrechen“ tippen, aber ein Banner erscheint, sodass dein Tipp auf „Bestätigen“ landet. Diese unerwartete Bewegung ist ein Layout Shift; Cumulative Layout Shift gibt ihr eine Zahl, die ihre Stärke beschreibt.

CLS ist eines der drei Core Web Vitals – der drei Metriken für die Seitenerfahrung, die Google neben Largest Contentful Paint (wie schnell der Hauptinhalt lädt) und Interaction to Next Paint (wie schnell die Seite auf einen Tipp reagiert) verfolgt. CLS betrifft die visuelle Stabilität: Bleibt die Seite ruhig?

Wie der Wert ungefähr funktioniert

CLS ist ein Wert, keine Zeitangabe. Ein CLS von 0,05 bedeutet nicht 50 Millisekunden von irgendetwas – es ist eine einheitenlose Zahl. Je größer der Bildschirmbereich ist, der sich bewegt, und je weiter er sich bewegt, desto höher und damit schlechter ist der Wert.

Die Zielwerte sind einfach:

• 0,1 oder weniger — gut.
• 0,1 bis 0,25 — verbesserungsbedürftig.
• Über 0,25 — schlecht.

Ein nützliches Detail: Shifts, die direkt nach deiner Aktion auftreten – etwa beim Tippen auf eine Schaltfläche oder beim Öffnen eines Menüs – werden der Seite nicht angelastet, weil du sie verursacht hast und erwartest. Es zählt nur die unerwartete Bewegung.

Warum CLS entsteht – und die Lösung

Fast jeder Layout Shift läuft auf dasselbe hinaus: Etwas wird geladen und nimmt Platz ein, den die Seite nicht reserviert hatte. Die wichtigsten Fälle:

• Bilder und Videos ohne Größenangaben. Der Browser weiß nicht, wie hoch das Bild ist, bis es eintrifft; deshalb wird der Text darunter nach unten geschoben. Die Lösung: Gib Bildern immer width und height (oder eine CSS-aspect-ratio), damit der Browser den Platz freihält.
• Anzeigen, Embeds und Iframes. Dasselbe Problem – reserviere dafür Platz.
• Webfonts. Wenn eine eigene Schrift die Fallback-Schrift ersetzt, kann sich der Text neu umbrechen.
• Eingeschobene Elemente. Cookie-Banner, „Das könnte dir auch gefallen“-Boxen und alles, was oberhalb des Inhalts eingefügt wird, den du gerade ansiehst.

Die Faustregel: Wenn etwas später erscheinen soll, lass dafür ein Loch in der richtigen Größe frei, damit sich beim Erscheinen nichts anderes bewegen muss.

Du möchtest die tatsächliche Formel, die Regel für das „Sitzungsfenster“, den Unterschied zwischen Labor- und Feldwerten sowie die vollständige Liste der Ursachen und Lösungen? Wechsle zum Tab Fortgeschritten.

TL;DR — CLS ist das Core Web Vital für visuelle Stabilität. Jeder Shift wird als impact fraction × distance fraction bewertet; die Metrik selbst ist das größte Sitzungsfenster von Shifts (≤ 1 s zwischen Shifts, ≤ 5 s Fenster) – nicht die Lebenszeitsumme, wie vor Juni 2021. Gut ist ≤ 0,1, verbesserungsbedürftig ≤ 0,25, schlecht > 0,25, am 75. Perzentil der Felddaten. Nur im Viewport sichtbare Shifts zählen; Shifts innerhalb von 500 ms einer diskreten Eingabe werden ausgeschlossen (Scrollen nicht). Ursachen sind Bilder/Videos/Anzeigen/Iframes/Embeds ohne Größen, Webfonts und über bestehende Inhalte eingeschobener Inhalt; Abhilfe schaffen reservierter Platz, font-display/size-adjust und Animationen ausschließlich mit transform. Die Falle: Lighthouse (Labor) liest routinemäßig nahezu 0, weil es nicht mit der Seite interagiert und nicht den gesamten Lebenszyklus ausführt – Felddaten (CrUX) sind das, was Google tatsächlich misst.

Was CLS misst

Googles Beschreibung lautet: „Cumulative Layout Shift (CLS) ist eine stabile Core-Web-Vital-Metrik. Sie ist eine wichtige nutzerzentrierte Metrik für die visuelle Stabilität, weil sie hilft zu quantifizieren, wie oft Nutzer unerwartete Layout Shifts erleben.“ Das entscheidende Wort ist unerwartet – Inhalte, die sich von selbst bewegen, nicht wegen einer Aktion des Nutzers.

CLS gehört mit Largest Contentful Paint (Ladezeit) und Interaction to Next Paint (Reaktionsfähigkeit) zum Trio der Core Web Vitals. Während LCP und INP in Millisekunden gemessen werden, ist CLS der Sonderfall: ein einheitenloser Verhältniswert. Das führt ständig zu Missverständnissen. Ein CLS von 0,05 sind nicht 50 ms; der Wert hat überhaupt keine Zeiteinheit.

Die Formel: Auswirkung × Entfernung

Google definiert den Wert pro Shift so:

layout shift score = impact fraction × distance fraction

• Impact fraction „misst, wie instabile Elemente die Viewport-Fläche zwischen zwei Frames beeinflussen“ – also die kombinierte sichtbare Fläche der bewegten Elemente vor und nach der Verschiebung als Anteil des Viewports.
• Distance fraction ist „die größte horizontale oder vertikale Entfernung, die sich ein instabiles Element im Frame bewegt hat, geteilt durch die größte Dimension des Viewports (Breite oder Höhe, je nachdem, was größer ist)“.

Beide Dimensionen zählen unabhängig voneinander. Ein kleines Element, das über fast den ganzen Bildschirm wandert, und ein großes Element, das nur leicht ruckelt, können sehr unterschiedliche Werte erreichen. Das Rechenbeispiel von web.dev: Eine Impact fraction von 0.75 und eine Distance fraction von 0.25 ergeben einen Layout-Shift-Wert von 0.1875.

Sitzungsfenster: der Teil, bei dem sich fast alle irren

Hier ist der am häufigsten falsch wiedergegebene CLS-Fakt und der, den du dir am meisten merken solltest: CLS ist nicht die Summe aller Shifts über die Lebensdauer der Seite. Früher war das so – das änderte sich im Juni 2021.

Heute gilt: „CLS misst den größten Burst von Layout-Shift-Werten für jeden unerwarteten Layout Shift, der während des gesamten Lebenszyklus einer Seite auftritt.“ Ein Burst ist ein Sitzungsfenster: „ein oder mehrere einzelne Layout Shifts treten schnell hintereinander auf, mit weniger als 1 Sekunde zwischen den Shifts und höchstens 5 Sekunden für die gesamte Fensterdauer.“ CLS ist der Wert des größten solchen Fensters – nicht die Summe und nicht der Durchschnitt.

Warum die Änderung? Die alte Definition, alles zu summieren, bestrafte langlebige Seiten stillschweigend. Eine Single-Page-App oder ein Infinite-Scroll-Feed sammelte allein durch seine längere Existenz mehr CLS, selbst wenn jeder einzelne Shift klein und gut verteilt war. Das Chrome-Speed-Metrics-Team wechselte zu einem maximalen Sitzungsfenster, um die Dauer nicht zu bestrafen, und wählte maximal statt durchschnittlich, damit die Behebung eines kleinen sekundären Shifts den Wert nicht paradoxerweise verschlechtert. Nach der Einführung bekam kein Origin einen schlechteren Wert, bei den meisten änderte sich nichts und ein Teil der langsamen UIs und Infinite-Scroll-Seiten verbesserte sich. Ein älterer Beitrag, der noch von der „Summe aller Shifts“ spricht, ist veraltet.

Was zählt – und was nicht

Drei Ausschlüsse bestimmen, was tatsächlich in deinen Wert eingeht:

• Unterhalb des Folds zählt es nicht. Bewertet werden nur Shifts von Inhalten, die im aktuellen Viewport sichtbar sind. Ein Shift am Ende einer langen Seite, zu dem der Nutzer nie scrollt, hat keine Auswirkung. In der Praxis bringt es fast immer mehr, sichtbare Shifts zu beheben, als weit unten auf der Seite nach ihnen zu suchen.
• Nutzerinitiierte Shifts erhalten 500 ms Schonfrist. „Layout Shifts, die innerhalb von 500 Millisekunden nach einer Nutzereingabe auftreten, erhalten das Flag hadRecentInput und können daher aus den Berechnungen ausgeschlossen werden.“ Google sagt: Shifts, „die als Reaktion auf Nutzerinteraktionen auftreten, sind im Allgemeinen in Ordnung, solange der Shift zeitlich nah genug an der Interaktion auftritt, dass der Zusammenhang für den Nutzer klar ist.“ Ein Akkordeon öffnen oder ein Menü aufklappen – diese Bewegung ist erwartet und wird verziehen.
• Scrollen ist aber keine Schonfrist. Der Ausschluss von 500 ms gilt nur für diskrete Ereignisse – Tippen, Klicken oder eine Tastenbetätigung. Kontinuierliche Gesten wie Scrollen oder Pinch-Zoom lösen das Ausschlussfenster nicht aus. Verschiebt sich Inhalt während des Scrollens, zählt das weiterhin. Diese Unterscheidung wird in vielen Darstellungen falsch erklärt; sie ist wichtig.

Schwellenwerte und Herkunft des Werts

„Für eine gute Nutzererfahrung sollten Websites einen CLS-Wert von 0,1 oder weniger anstreben“, gemessen am „75. Perzentil der Seitenaufrufe, aufgeteilt nach Mobil- und Desktopgeräten“. Die vollständigen Bereiche sind:

• Gut: ≤ 0,1
• Verbesserungsbedürftig: 0,1–0,25
• Schlecht: > 0,25

Die Grenze von 0,1 ist nicht willkürlich. Googles Nutzerforschung ergab, dass „Shift-Werte ab 0,15 durchgehend als störend wahrgenommen wurden, während Shifts von 0,1 und weniger zwar auffielen, aber nicht übermäßig störend waren.“ Man entschied sich unter anderem deshalb für 0,1 statt für eine strengere Grenze, weil Drittanbieter-Embeds wie Anzeigen und soziale Widgets so häufig Shifts verursachen, dass ein strengerer Maßstab für das echte Web unpraktisch wäre.

Der Teil „75. Perzentil der Felddaten“ ist entscheidend – und führt uns zur größten Messfalle.

Labor und Feld: Warum die Werte nicht übereinstimmen

Hier tappt die Mehrheit in die Falle. Lighthouse und andere Labortools melden oft einen CLS nahe 0,0, während Felddaten – und Google – einen deutlich schlechteren Wert zeigen. Der Unterschied bedeutet nicht, dass eines der Tools unehrlich ist; es geht um den Umfang. Ein Labortest ist ein einzelner, kurzer, skriptgesteuerter Seitenaufruf: Er scrollt nicht, klickt nicht und bleibt nicht lange genug, sondern erfasst nur Shifts beim initialen Laden. Felddaten (CrUX) aggregieren echte Besuche vieler Nutzer, Geräte und Navigationen über ein rollierendes Fenster; CLS ist für den gesamten Lebenszyklus der Seite definiert – Menüs werden geöffnet, Lazy Content lädt beim Scrollen, späte Anzeigen werden gefüllt, und die Sitzung kann beliebig lange dauern. Ein kurzer Labortest kann den Großteil davon strukturell nicht sehen.

Die praktische Regel lautet daher: Nutze Labordaten zum Debuggen eines bestimmten Shifts und Felddaten, um deinen echten Wert zu kennen. Google rankt anhand von Felddaten aus dem Chrome User Experience Report (CrUX), die in PageSpeed Insights und der Search Console sichtbar sind. Wenn Lighthouse 0,0 liest, PageSpeed Insights aber 0,18 zeigt, behandle den Feldwert als denjenigen, der deine tatsächlichen Nutzer widerspiegelt – und reproduziere den Shift anschließend im Labor, indem du wie ein echter Besucher mit der Seite interagierst. Zwei weitere Unterschiede im Umfang sind wichtig: Die meisten Tools einschließlich Lighthouse übertragen Layout Shifts aus Iframes nicht in den Wert des übergeordneten Dokuments, obwohl CrUX sie berücksichtigen kann. Auch RUM auf Basis der Layout Instability API hat diesen blinden Fleck bei Iframes; deshalb kann dein eigenes Real-User-Monitoring einen CrUX-Wert, der schlechter aussieht als deine First-Party-Zuordnung, nicht vollständig erklären.

Die häufigsten Ursachen

Ungefähr in der Reihenfolge, in der ich sie antreffe:

1. Bilder und Videos ohne Abmessungen. Ohne reservierte Höhe springt alles darunter, sobald das Medium geladen ist.
2. Anzeigen, Embeds und Iframes ohne reservierten Platz. Werbenetzwerke liefern dynamische Größen; Embeds kündigen ihre Höhe vor dem Laden nicht an.
3. Dynamisch oberhalb bestehender Inhalte eingefügter Inhalt. Cookie-Banner, Hinweisleisten, „Verwandt“-Widgets, spät geladene Werbeaktionen – alles, was bereits sichtbaren Inhalt nach unten schiebt.
4. Webfonts (FOIT/FOUT). Wenn die eigene Schrift die Fallback-Schrift ersetzt, läuft der Text neu um, falls sich ihre Metriken unterscheiden.
5. Animationen von Layout-auslösenden Eigenschaften. Das Animieren von top, left, margin, box-shadow oder box-sizing zwingt den Browser, die Seite in jedem Frame neu zu layouten.

Die Lösungen

Jede Lösung entspricht ihrer Ursache:

• Bilder/Videos – Platz reservieren. Setze die Attribute width und height, damit der Browser das Seitenverhältnis berechnet und den Bereich freihält; kombiniere das für responsive Verhalten mit img { height: auto; width: 100%; } oder verwende die CSS-Eigenschaft aspect-ratio. Auf den meisten Websites ist das die CLS-Maßnahme mit dem größten Hebel.
• Anzeigen/Embeds/Iframes – ebenfalls Platz reservieren. Nutze min-height oder aspect-ratio am Container. Für Anzeigenplätze ist Googles Publisher-Tag-Empfehlung eindeutig: „Eine feste Höhe und Breite direkt am div des Anzeigenplatzes festzulegen, ist die wirksamste Methode.“ Bei Plätzen mit mehreren Größen reservierst du den Platz für die größte konfigurierte Größe. Schiebe spät ladenden Inhalt nach unten, damit ein verbleibender Shift unterhalb des Folds liegt.
• Dynamischer Inhalt – nicht in den Fluss einsetzen. Reserviere einen Platzhalter in der endgültigen Größe oder lege den Inhalt über, statt ihn einzufügen. Skeleton-Loader helfen nur, wenn sie exakt die endgültigen Abmessungen haben – ein Skeleton, das nur wenige Pixel kürzer als der echte Inhalt ist, verursacht weiterhin einen Shift. Bevorzuge vom Nutzer ausgelöste Ladevorgänge („Mehr laden“) gegenüber überraschenden Einfügungen.
• Schriften – Metriken angleichen. font-display: optional ist der einzige Wert mit praktisch null CLS-Risiko; swap verkürzt die Zeit unsichtbaren Textes, kann beim Austausch aber einen Shift erzeugen. Noch besser sind die CSS-Metriküberschreibungen size-adjust, ascent-override, descent-override und line-gap-override, mit denen du die Fallback-Schrift an die Webfont anpasst. Kritische Schriften vorladen.
• Animationen – nur transform. Animieren solltest du mit transform (translate, scale, rotate) statt mit top, left oder margin. Transform-basierte Animationen werden zusammengesetzt und lösen kein neues Layout aus; dadurch verschieben sie nichts.

Wie CLS in Rankings einzuordnen ist

CLS ist ein Eingangswert für Googles Signal zur Seitenerfahrung. Google sagt, dass Core Web Vitals von seinen Rankingsystemen verwendet werden – die aktuelle Search-Dokumentation veröffentlicht aber weder ein genaues CLS-Gewicht noch eine Tie-Breaker-Regel oder eine Ranking-Garantie. Behandle jede konkrete Mechanik, auch „CLS ist ein Tie-Breaker“, deshalb als Arbeitsnäherung und nicht als dokumentierte Tatsache. Mein ständiger Rat zu Core Web Vitals lautet: Erreiche den Bereich „Gut“ und mach weiter. Die meisten Websites sehen keinen messbaren Ranking- oder Geschäftseffekt, wenn sie 0,08 auf 0,02 drücken; ein einzelner Wert erklärt selten allein Umsatz oder Conversion. CLS gehört zur Grundausstattung – die Grenze sollte überschritten werden, aber CLS darf nicht zum Mittelpunkt deines SEO-Programms werden und dabei LCP, INP oder schlicht deinen eigentlichen Inhalt verdrängen.

Zwei operative Hinweise ersparen viel Verwirrung:

• CrUX hinkt ungefähr 28 Tage hinterher. Es ist ein rollierendes 28-Tage-Fenster. Eine heute veröffentlichte Korrektur wird sich in PageSpeed Insights oder der Search Console daher erst nach Wochen vollständig zeigen. Keine Panik, wenn sich der Wert am nächsten Morgen nicht bewegt.
• Das zugeordnete Element ist oft nicht die Root Cause. Die Layout Shift Attribution API zeigt, welches Element sich bewegt hat; web.dev weist aber darauf hin, dass „diese Elemente möglicherweise nur indirekt mit der ‚Root Cause‘ der Layout-Instabilität zusammenhängen“. Der gesprungene Text ist meist das Opfer eines unsized Bildes darüber, das spät geladen wurde – behebe die Ursache, nicht das Symptom. Arbeite mit einer Zeitstempel-zu-Trigger-Schleife: Notiere die Startzeit des Shifts und prüfe dann, was sich im selben Zeitfenster sonst geändert hat – eine abgeschlossene Netzwerkanfrage, ein eingetroffenes Bild oder eine Schrift, eine Größenänderung oder eine Klassen-/Stiländerung. Behandle den zugeordneten Knoten als Hinweis, nicht als Beweis, bis du ihn diesem Trigger zuordnen kannst.

KI-Zusammenfassung

Eine komprimierte Fassung der Advanced-Version:

• CLS = visuelle Stabilität, das Core Web Vital für unerwartete Bewegungen sichtbarer Inhalte. Es steht neben Largest Contentful Paint und Interaction to Next Paint.
• Es ist ein einheitenloser Wert, keine Zeit. 0,05 ist ein Verhältnis, keine 50 ms.
• Formel pro Shift: impact fraction × distance fraction – wie viel des Viewports sich bewegt hat, multipliziert mit der Entfernung relativ zur größten Viewport-Dimension.
• Die Metrik ist das größte Sitzungsfenster (≤ 1 s zwischen Shifts, ≤ 5 s insgesamt) – nicht die Lebenszeitsumme. Das wurde im Juni 2021 geändert, um langlebige/SPA-Seiten nicht zu bestrafen; man wählte das Maximum statt des Durchschnitts.
• Schwellenwerte (75. Perzentil, Felddaten): Gut ≤ 0,1 · Verbesserungsbedürftig ≤ 0,25 · Schlecht > 0,25.
• Ausschlüsse: Shifts unterhalb des Folds zählen nicht; Shifts innerhalb von 500 ms einer diskreten Eingabe (Tippen/Klick/Taste) werden ausgeschlossen – Scrollen ist nicht ausgenommen.
• Ursachen: Bilder/Videos/Anzeigen/Iframes/Embeds ohne Größen, oberhalb bestehenden Inhalts eingeschobener Inhalt, Webfonts sowie Animationen von Layout-auslösenden Eigenschaften.
• Lösungen: width/height oder aspect-ratio setzen; Platz für dynamischen Inhalt reservieren (Skeletons müssen exakt passen); font-display plus size-adjust; nur mit transform animieren.
• Labor ≠ Feld. Lighthouse liest oft nahezu 0, weil es nicht mit der Seite interagiert und nicht den gesamten Lebenszyklus ausführt; Felddaten (CrUX/PageSpeed Insights) sind das, worauf Google rankt. Iframe-Shifts werden im Labor und in RUM-Tools meistens nicht an den Wert des übergeordneten Dokuments weitergegeben.
• Ranking: ein Eingangswert, den Google für seine Rankingsysteme innerhalb der Seitenerfahrung nennt – es gibt kein dokumentiertes Gewicht und keine Tie-Breaker-Regel. Erreiche also „Gut“ und mach weiter, statt einer bestimmten Mechanik nachzujagen. CrUX hinkt ungefähr 28 Tage hinterher; das zugeordnete Element ist oft nicht die Root Cause.

Offizielle Dokumentation

Primärquellen von Google und dem Chrome-Team.

Zentrale CLS-Dokumente

• Cumulative Layout Shift (CLS) — die maßgebliche Definition, die Formel Auswirkung × Entfernung, Sitzungsfenster, Schwellenwerte und den hadRecentInput-Ausschluss (Milica Mihajlija und Philip Walton).
• Optimize Cumulative Layout Shift — der offizielle Leitfaden zu Ursachen und Lösungen: Bilder, Anzeigen/Embeds, eingeschobener Inhalt, Schriften und Animationen.
• Debug layout shifts — Shifts in Chrome DevTools, das Layout-Shift-Regions-Overlay und die LayoutShiftAttribution API finden (Katie Hempenius und Barry Pollard).

Hintergrund und Messung

• Weiterentwicklung von Cumulative Layout Shift in Web-Werkzeugen — warum die Metrik im Juni 2021 von der Summe aller Shifts zum größten Sitzungsfenster wechselte (Annie Sullivan und Hongbo Song, Chrome-Team für Geschwindigkeitsmetriken).
• So wurden die Schwellenwerte der Core-Web-Vitals-Metriken festgelegt — Nutzerforschung und Erreichbarkeitsdaten hinter den Bereichen 0,1/0,25.
• Erste Schritte beim Messen der Web Vitals — Labor- und Felddaten und warum der CLS im Labor künstlich niedrig sein kann.
• Font best practices — font-display, Metriküberschreibungen und Vorladen für schriftbedingte Shifts.

Anzeigen und Suche

• Minimize layout shift — Googles Publisher-Tag-Empfehlungen zum Reservieren von Platz für Anzeigenplätze.
• Core Web Vitals und ihre Bedeutung für Google-Suchergebnisse — wie CWV einschließlich CLS in die Suche einfließen.

Zitate aus den Quellen

Wörtlich dokumentierte Aussagen von Google und dem Chrome-Team. Jeder Link führt direkt zur zitierten Passage auf der Quellseite.

Google – was CLS ist

• “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (Übersetzung) „Cumulative Layout Shift (CLS) ist eine stabile Core-Web-Vital-Metrik. Sie ist eine wichtige nutzerzentrierte Metrik für die visuelle Stabilität, weil sie hilft zu quantifizieren, wie oft Nutzer unerwartete Layout Shifts erleben.“ Zum Zitat
• “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (Übersetzung) „CLS misst den größten Burst von Layout-Shift-Werten für jeden unerwarteten Layout Shift, der während des gesamten Lebenszyklus einer Seite auftritt.“ Zum Zitat

Google – die Formel

• “layout shift score = impact fraction * distance fraction” (Übersetzung) „layout shift score = impact fraction × distance fraction“ Zum Zitat
• “The impact fraction measures how unstable elements impact the viewport area between two frames.” (Übersetzung) „Die Impact fraction misst, wie instabile Elemente die Viewport-Fläche zwischen zwei Frames beeinflussen.“ Zum Zitat
• “The distance fraction is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” (Übersetzung) „Die Distance fraction ist die größte horizontale oder vertikale Entfernung, die sich ein instabiles Element im Frame bewegt hat, geteilt durch die größte Dimension des Viewports (Breite oder Höhe, je nachdem, was größer ist).“ Zum Zitat

Google – Sitzungsfenster

• “A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” (Übersetzung) „Ein Burst von Layout Shifts, auch Sitzungsfenster genannt, liegt vor, wenn ein oder mehrere einzelne Layout Shifts schnell hintereinander auftreten, mit weniger als 1 Sekunde zwischen den Shifts und höchstens 5 Sekunden für die gesamte Fensterdauer.“ Zum Zitat

Google – Schwellenwerte und Nutzereingaben

• “To provide a good user experience, sites should strive to have a CLS score of 0.1 or less… a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (Übersetzung) „Für eine gute Nutzererfahrung sollten Websites einen CLS-Wert von 0,1 oder weniger anstreben … ein guter Messwert ist das 75. Perzentil der Seitenaufrufe, aufgeteilt nach Mobil- und Desktopgeräten.“ Zum Zitat
• “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” (Übersetzung) „Layout Shifts, die innerhalb von 500 Millisekunden nach einer Nutzereingabe auftreten, erhalten das Flag hadRecentInput und können daher aus den Berechnungen ausgeschlossen werden.“ Zum Zitat
• “Layout shifts that occur in response to user interactions (such as clicking or tapping a link, pressing a button, or typing in a search box) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” (Übersetzung) „Layout Shifts, die als Reaktion auf Nutzerinteraktionen auftreten (etwa durch Klicken oder Tippen auf einen Link, Drücken einer Schaltfläche oder Eingeben in ein Suchfeld), sind im Allgemeinen in Ordnung, solange der Shift zeitlich nah genug an der Interaktion auftritt, dass der Zusammenhang für den Nutzer klar ist.“ Zum Zitat

Google – wie die Schwellenwerte gewählt wurden

• “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” (Übersetzung) „Shift-Werte ab 0,15 wurden durchgehend als störend wahrgenommen, während Shifts von 0,1 und weniger zwar auffielen, aber nicht übermäßig störend waren.“ Zum Zitat

Google – Platz für Anzeigenplätze reservieren

• “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (Übersetzung) „Eine feste Höhe und Breite direkt am div des Anzeigenplatzes festzulegen, ist die wirksamste Methode.“ Zum Zitat

Google – zugeordnetes Element und Root Cause

• “elements listed as sources are the elements that shifted during the layout shift. However, it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (Übersetzung) „Bei den als Quellen aufgeführten Elementen handelt es sich um die Elemente, die sich während des Layout Shifts bewegt haben. Es ist jedoch möglich, dass diese Elemente nur indirekt mit der ‚Root Cause‘ der Layout-Instabilität zusammenhängen.“ Zum Zitat

Checkliste: CLS-Ursachen → Lösungen

Arbeite von oben nach unten; die ersten beiden Punkte beheben den Großteil des CLS in der Praxis.

• Jedes <img> und <video> hat width und height (oder eine CSS-aspect-ratio), bei responsiven Layouts mit img { height: auto; width: 100%; }.
• Anzeigenplätze, Iframes und Embeds reservieren Platz über min-height/aspect-ratio; Anzeigenplätze mit mehreren Größen reservieren den Platz für die größte konfigurierte Größe.
• Spät ladender Inhalt liegt möglichst unterhalb des Folds, damit ein verbleibender Shift nicht zählt.
• Eingeschobener Inhalt (Cookie-Banner, Werbeaktionen, „Verwandt“-Widgets) wird überlagert oder vorab reserviert – er wird nicht über bestehendem Inhalt eingefügt.
• Skeleton-Platzhalter haben exakt die Abmessungen des endgültigen Inhalts (ein paar Pixel Unterschied verursachen weiterhin einen Shift).
• Webfonts nutzen font-display: optional, wenn das vertretbar ist, oder swap plus size-adjust/ascent-override, um die Fallback-Metriken anzupassen; kritische Schriften werden vorgeladen.
• Animationen verwenden ausschließlich transform – niemals top, left, margin, box-shadow oder box-sizing.
• Der Wert wurde in den Felddaten geprüft (PageSpeed Insights/Search Console/CrUX), nicht nur in Lighthouse.
• Shifts wurden durch Interaktion mit der Seite reproduziert – Scrollen, Menüs öffnen, Lazy Loads auslösen – nicht nur beim initialen Laden.
• Shifts von Anzeigen/Iframes wurden in den Felddaten verifiziert (Labortools übertragen sie oft nicht an den Wert des übergeordneten Dokuments).

CLS-Spickzettel

Die Zahlen

Die Definition in einer Zeile

• layout shift score = impact fraction × distance fraction (pro Shift).
• CLS = das größte Sitzungsfenster von Shifts – ≤ 1 s zwischen Shifts, höchstens 5 s für das gesamte Fenster. Nicht die Lebenszeitsumme (die galt vor Juni 2021).
• Es ist ein einheitenloser Wert, keine Zeitangabe.

Was ausgeschlossen wird

• Shifts unterhalb des Folds (nicht im aktuellen Viewport).
• Shifts innerhalb von 500 ms nach einer diskreten Eingabe (Tippen/Klick/Taste) – hadRecentInput.
• Nicht ausgeschlossen: Shifts beim Scrollen oder Pinch-Zoom (kontinuierliche Gesten).

Ursachen → Lösungen

Messfallen

• Lighthouse (Labor) liest oft ungefähr 0 – es interagiert nicht mit der Seite und führt nicht den gesamten Lebenszyklus aus. CrUX/PageSpeed Insights (Feld) ist das, worauf Google rankt.
• CrUX hinkt ungefähr 28 Tage hinterher – Korrekturen brauchen Wochen, bis sie sichtbar werden.
• Iframe-Shifts werden in Labortools normalerweise nicht an den Wert des übergeordneten Dokuments weitergegeben.
• Das zugeordnete Element ist das bewegte Element, nicht unbedingt die Root Cause.

Werkzeuge zum Messen und Debuggen von CLS

Felddaten (worauf Google rankt)

• PageSpeed Insights — CrUX-Feld-CLS auf Seiten- und Origin-Ebene sowie ein Lighthouse-Labortest direkt daneben. Der schnellste Weg, den Unterschied zwischen Labor und Feld selbst zu sehen.
• Search Console – Core-Web-Vitals-Bericht — CLS aus den Felddaten für URL-Gruppen über die gesamte Website, nach Status gruppiert.
• CrUX (Chrome User Experience Report) — der zugrunde liegende Felddatensatz; die Historie lässt sich über CrUX-Dashboards oder BigQuery untersuchen.

Labordaten (zum Debuggen)

• Chrome DevTools – Performance-Panel — eine Aufzeichnung erstellen und die Spur Layout Shifts lesen; wenn du auf einen Shift klickst, werden die bewegten Elemente hervorgehoben und der Shift-Wert angezeigt. Live Metrics aktualisiert CLS in Echtzeit, während du interagierst.
• Overlay für Layout-Shift-Regionen — DevTools → Einstellungen → Weitere Tools → Rendering → Layout Shift Regions. Neu laden; die sich verschiebenden Bereiche blinken, sodass du sie sehen kannst.
• Lighthouse — schneller Laborwert für CLS; denk aber daran, dass es nur Shifts beim initialen Laden erfasst.
• WebPageTest — CLS im Labor mit Filmstreifen und Trace.

RUM (deine eigenen Felddaten)

• web-vitals-JavaScript-Bibliothek — onCLS() meldet CLS realer Nutzer aus deinen eigenen Besuchen (ungefähr 2 KB); das ist das genaueste Bild dessen, was Menschen tatsächlich erleben.
• PerformanceObserver (layout-shift) — die von der Bibliothek gekapselte Roh-API plus LayoutShiftAttribution-sources, die angeben, welche Elemente sich bewegt haben.

Wie die Tools selbst bewerten

Ein Live-Beispiel für die hier beschriebene Metrik: bekannte Page-Speed- und Monitoring-Dienste, geordnet nach ihrem mobilen CLS aus echten Nutzerdaten (Felddaten des Chrome UX Report):

Welche CLS-Korrektur solltest du zuerst umsetzen?

CLS-Fehler, die das eigentliche Problem verbergen

Einen sauberen Lighthouse-Lauf als Beweis behandeln

Lighthouse kann fertig sein, bevor ein Consent-Banner, eine Anzeige oder ein durch Interaktion ausgelöster Shift auftritt. Nutze den Labortest zum Debuggen, prüfe aber CrUX oder dein eigenes Real-User-Monitoring, bevor du das Problem für behoben erklärst.

Nur das von DevTools gemeldete bewegte Element reparieren

Das bewegte Element ist oft das Opfer. Ein spät geladenes Element darüber kann die Ursache sein. Spiele den Trace erneut ab und prüfe, was unmittelbar vor der Bewegung eingefügt wurde oder seine Größe geändert hat.

Platz mit einer geratenen festen Höhe reservieren

Ein fester Platzhalter kann einen zweiten Shift erzeugen, wenn responsive Inhalte höher oder niedriger sind. Verwende intrinsische Abmessungen oder aspect-ratio, wenn die Proportionen des Inhalts bekannt sind.

Layout-Eigenschaften animieren

Wenn du top, left oder Margins veränderst, kann sich der umgebende Inhalt bewegen. Animieren solltest du mit transform, wenn der Effekt den Dokumentfluss nicht ändern muss.

Ein CLS-Problem anhand des Symptoms diagnostizieren

Der Feld-CLS ist schlecht, aber der Laborwert liegt nahe null

Wahrscheinliche Ursache: Der Shift tritt nach einer Interaktion, während einer längeren Sitzung oder nur bei einer Teilmenge der Nutzer auf. Lösung: Reproduziere den echten Ablauf mit einer Aufzeichnung des Performance-Panels und ergänze web-vitals-Attribution im Real-User-Monitoring. Bestätigung: Die auslösende Interaktion und das bewegte Element erscheinen im Trace oder im RUM-Eintrag.

Text springt, sobald die eigene Schrift eintrifft

Wahrscheinliche Ursache: Fallback- und Webfont verwenden unterschiedliche Metriken. Lösung: Lade die kritische Schrift, wo angemessen, vor und gleiche die Fallback-Schrift mit Metriküberschreibungen an. Bestätigung: Wiederhole den Test bei deaktiviertem Cache und prüfe, dass die Spur „Layout Shifts“ den Austausch nicht mehr aufzeichnet.

Ein Banner oder eine Anzeige schiebt die Seite nach unten

Wahrscheinliche Ursache: Für den Platz wurden vor dem Eintreffen des Inhalts keine festen Abmessungen reserviert. Lösung: Lege einen stabilen Container an oder platziere die Nachricht so, dass sie keinen sichtbaren Inhalt verdrängt. Bestätigung: Bremse das Laden und beobachte, ob der Platz seine Grundfläche behält.

CLS verbessert sich im Test, aber nicht in PageSpeed Insights

Wahrscheinliche Ursache: CrUX ist ein rollierender Felddatensatz und keine unmittelbare Prüfung des Deployments. Lösung: Prüfe die Änderung zuerst im Labor und in RUM; warte danach, bis sich das Feldfenster erneuert. Bestätigung: Deine eigene Feldverteilung nach dem Release verbessert sich, bevor das öffentliche CrUX-Aggregat folgt.

Layout Shifts im Browser aufzeichnen

Füge dies in die DevTools-Konsole ein, bevor du das Problem reproduzierst. Es ignoriert Shifts, die an eine kürzliche Nutzereingabe gebunden sind, und gibt den Wert sowie die Elemente aus, denen der Browser den Shift zugeordnet hat.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.table({
      value: entry.value,
      time: Math.round(entry.startTime),
      elements: entry.sources?.map((source) => source.node),
    });
  }
});

observer.observe({ type: 'layout-shift', buffered: true });

Der zugeordnete Knoten ist ein Hinweis und kein automatischer Beweis der Ursache. Vergleiche seinen Zeitstempel im selben Trace mit Netzwerkanfragen, geladenen Schriften und DOM-Einfügungen.

Beweisen, dass eine CLS-Korrektur funktioniert

Test für reservierten Platz

Auszuführender Test: Deaktiviere den Cache, drossele die Verbindung, lade neu und zeichne die Spur „Layout Shifts“ im Performance-Panel auf. Erwartetes Ergebnis: Das Medium oder Embed behält vor und nach dem Laden dieselbe Grundfläche. Interpretation eines Fehlers: Die Größe des Containers hängt weiterhin von spät eintreffendem Inhalt ab. Beobachtungsfenster: Sofort im Trace. Rollback-Auslöser: Der neue Platzhalter verursacht Abschneiden, übermäßig viel Leerraum oder einen neuen Shift an einem responsiven Breakpoint.

Test für den Schriftaustausch

Auszuführender Test: Lade bei deaktiviertem Cache neu und beobachte Text und die Spur „Layout Shifts“. Erwartetes Ergebnis: Der Übergang von der Fallback- zur Webfont erzeugt keinen messbaren Shift. Interpretation eines Fehlers: Die Fallback-Metriken unterscheiden sich weiterhin oder die kritische Schrift kommt zu spät. Beobachtungsfenster: Sofort bei wiederholten Labortests. Rollback-Auslöser: Die Änderung blendet Text länger aus oder macht die endgültige Typografie deutlich unpassend.

Bestätigung in den Felddaten

Auszuführender Test: Vergleiche die onCLS()-Daten nach dem Release für das geänderte Template mit der Baseline vor dem Release und beobachte anschließend CrUX. Erwartetes Ergebnis: Das p75 bei echten Nutzern verbessert sich, ohne dass sich der Long Tail bei wichtigen Abläufen verschlechtert. Interpretation eines Fehlers: Eine weitere späte oder interaktionsbedingte Ursache ist noch vorhanden. Beobachtungsfenster: RUM, sobald Traffic eintrifft; CrUX über das rollierende 28-Tage-Fenster. Rollback-Auslöser: CLS oder Interaktionsfehler verschlechtern sich nach dem Release dauerhaft.

CLS-Metriken, die sich zu verfolgen lohnen

CLS echter Nutzer am p75

Metrik: CLS am 75. Perzentil für jedes wichtige Template und jede Geräteklasse. Was sie zeigt: Ob die meisten Besuche das Ziel für visuelle Stabilität erreichen. So wird sie abgerufen: CrUX, PageSpeed Insights oder web-vitals-RUM. Benchmark / realistische Spanne: Gut ist 0,1 oder weniger; 0,1–0,25 ist verbesserungsbedürftig; über 0,25 ist schlecht. Taktung: Releases in RUM überwachen und den rollierenden Feldtrend monatlich prüfen.

Anteil schlechter Besuche

Metrik: Anteil der echten Besuche mit CLS über 0,25. Was sie zeigt: Ob ein akzeptables p75 einen schädlichen Long Tail verdeckt. So wird sie abgerufen: Deine onCLS()-Ereignisse nach Template und Ablauf in Buckets einteilen. Benchmark / realistische Spanne: Eine Website-Baseline festlegen und den schlechten Bucket senken; die Traffic-Mischung macht ein universelles Ziel irreführend. Taktung: Bei stark frequentierten Templates wöchentlich und nach Layout-Releases.

Shift-Attribution nach Ursache

Metrik: Layout-Shift-Einträge, gruppiert nach Element oder Komponente. Was sie zeigt: Welche wiederkehrende Implementierung die meiste Instabilität verursacht. So wird sie abgerufen: Der Attribution-Build von web-vitals oder PerformanceObserver. Benchmark / realistische Spanne: Es gibt keine universelle Spanne; Komponenten nach Gesamtauswirkung und betroffenen Besuchen vergleichen. Taktung: Bei jedem Release eines Templates oder einer Komponente prüfen.

Ressourcen, die deine Zeit wert sind

Offiziell und ausführlich

• Cumulative Layout Shift (CLS) — die maßgebliche Referenz.
• Optimize Cumulative Layout Shift — der offizielle Leitfaden zu Korrekturen.
• Debug layout shifts — der DevTools-Workflow.
• Weiterentwicklung von Cumulative Layout Shift in Web-Werkzeugen — die Änderung zum Sitzungsfenster im Juni 2021, erklärt vom verantwortlichen Team.

Von Praktikern

• So beheben Sie Probleme mit Cumulative Layout Shift (CLS) — Barry Pollard, Smashing Magazine. Geht ausführlich auf Schriftdeskriptoren und das Problem ein, dass das bewegte Element nicht die eigentliche Ursache ist.
• Cumulative Layout Shift in Practice — Nic Jansma (Cloudflare; W3C Web Performance WG). Die beste Darstellung der Messnuancen: Iframe-Attributionslücken, die Attribution-Stichprobe mit fünf Elementen und Unterschiede zwischen Tools.
• Cumulative Layout Shift messen und optimieren — DebugBear.
• Der nahezu vollständige Leitfaden zu Cumulative Layout Shift — Jess Peck. Gründliche Behandlung von Sonderfällen einschließlich Shifts bei SPA-Navigationen und der Ausschlussnuancen kontinuierlicher Gesten.
• Layout shift culprits — Chrome-DevTools-Dokumentation zum CLS-Culprit-Insight-Panel, eine nützliche Ergänzung zum web.dev-Debug-Leitfaden.
• So beheben Sie Cumulative Layout Shift (CLS) — Kinsta. Praktischer CMS-Leitfaden mit WordPress-spezifischen Ursachen wie Galerie-Bildern, spät ladenden Widgets und Cookie-Bannern.
• Layout Instability API — WICG-Spezifikation. Die zugrunde liegende Browser-API von CLS; nützlich für eigenes RUM oder wenn du die genaue Semantik von hadRecentInput brauchst.

Wo es in meine Arbeit passt

• CLS erscheint in meiner Core-Web-Vitals-Berichterstattung als „Grundausstattung“ – verfolge den Wert, erreiche den guten Bereich und halte ihn im Verhältnis zu LCP, INP und deinem Inhalt. Google veröffentlicht kein genaues CLS-Gewicht und keine Tie-Breaker-Regel; es ist also ein Eingangswert, den du beobachten solltest, nicht das ganze Spiel.

Statistiken, die sich zitieren lassen

• Die Grenze von 0,1 ist in Wahrnehmungsforschung begründet. Googles Nutzerstudien ergaben, dass Shifts von 0,15 und höher durchgehend als störend wahrgenommen wurden, während 0,1 und weniger zwar auffielen, aber nicht übermäßig störend waren. Quelle
• CLS ist das am leichtesten zu bestehende Core Web Vital. In meinen Enterprise-Audits ist das Muster konsistent: Eine große Mehrheit der Websites überschreitet die CLS-Grenze (oft etwa 80 % oder mehr), aber nur etwas mehr als die Hälfte besteht alle drei Vitals gemeinsam – CLS hält dich selten allein zurück.
• Die Änderung vom Juni 2021 half und schadete nie. Als CLS zum größten Sitzungsfenster wechselte, erhielt kein Origin einen schlechteren Wert, bei den meisten änderte sich nichts und ein Teil der Infinite-Scroll- und Slow-UI-Seiten verbesserte sich. Quelle
• Medien ohne Größenangaben gibt es weiterhin überall. Branchen-Crawls (Web Almanac) finden regelmäßig einen großen Anteil von Seiten, die Bilder ohne explizite Abmessungen ausliefern – die häufigste CLS-Ursache und zugleich die leichteste Korrektur.
• 72 % der Websites weltweit erreichen inzwischen einen guten CLS (Web Almanac/HTTP-Archive-Daten 2025). Damit ist CLS das am leichtesten zu bestehende Core Web Vital; trotzdem liefern 62 % der mobilen Seiten noch mindestens ein Bild ohne explizite Abmessungen aus, die häufigste Ursache. Quelle: HTTP Archive / Web Almanac
• Geschäftliche Auswirkung: Rakuten 24 berichtete bei Nutzern mit niedrigem CLS einen Umsatzanstieg pro Besucher von 53,37 % gegenüber Nutzern mit hohem CLS – eine häufig zitierte Fallstudie, aber kein Beleg dafür, dass ein bestimmter CLS-Wert auf anderen Websites einen bestimmten Geschäftseffekt verursacht. Quelle: corewebvitals.io case studies

Videos

• Googles Such- und Chrome-Entwicklerteams (YouTube) — Rundgänge zu Core Web Vitals und zur Fehlersuche bei Layout Shifts, einschließlich DevTools-Demos der Spur „Layout Shifts“ und des Overlays für Layout-Shift-Regionen. Kanal

Teste dich selbst: Cumulative Layout Shift

Fünf kurze Fragen zum Messen und Beheben visueller Instabilität. Wähle für jede eine Antwort und prüfe sie anschließend.

Änderungsprotokoll