Cumulative Layout Shift (CLS) ist eine Kennzahl aus Googles Core Web Vitals und misst, wie stark sich sichtbare Inhalte einer Website während der Nutzung unerwartet verschieben. Typisches Beispiel: Ein nachladendes Bild oder Werbebanner drückt den Text nach unten, während man gerade liest oder klicken will. Je niedriger der Wert, desto stabiler die Seite; als gut gilt ein CLS bis 0,1.
Was ist Cumulative Layout Shift?
Cumulative Layout Shift (CLS) ist eine Kennzahl aus Googles Core Web Vitals und misst, wie stark sich sichtbare Inhalte einer Website während der Nutzung unerwartet verschieben. Typisches Beispiel: Ein nachladendes Bild oder Werbebanner drückt den Text nach unten, während man gerade liest oder klicken will. Je niedriger der Wert, desto stabiler die Seite; als gut gilt ein CLS bis 0,1. Die offizielle Definition liefert Googles web.dev-Dokumentation.
CLS steht neben dem Largest Contentful Paint und dem Interaction to Next Paint als eine von drei Core-Web-Vitals-Metriken. Gemeinsam beschreiben sie zentrale Aspekte der User Experience und fließen in Googles Bewertung der Pagespeed und Seitennutzererfahrung ein.
Anders als reine Ladezeit-Metriken misst der CLS ein Erlebnis, das jeder kennt: das Gefühl, dass eine Seite unter den eigenen Fingern springt. Damit ist er ein sehr direkter Ausdruck von Usability — eine visuell stabile Seite wirkt vertrauenswürdig und beherrschbar, eine springende dagegen billig und fehleranfällig. Für Seiten mit Conversion-Zielen wirkt sich das unmittelbar auf die Conversion-Rate aus.
Wie wird der Cumulative Layout Shift gemessen?
Der Browser registriert jede unerwartete Verschiebung sichtbarer Elemente und berechnet daraus einen Wert, der sich aus dem betroffenen Anteil des sichtbaren Bereichs und der Distanz der Verschiebung zusammensetzt. Mehrere kurz aufeinanderfolgende Verschiebungen werden zu Gruppen zusammengefasst; die größte Gruppe bestimmt den CLS der Seite. Layout-Verschiebungen, die direkt auf eine Nutzeraktion folgen — etwa das Aufklappen eines Menüs nach einem Klick — zählen nicht als unerwartet und fließen nicht ein.
Google bewertet den CLS wie alle Core Web Vitals anhand realer Nutzerdaten am 75. Perzentil: Bis 0,1 gilt als gut, zwischen 0,1 und 0,25 als optimierungsbedürftig, darüber als schlecht. Messbar ist der Wert über die Google Search Console, PageSpeed Insights und die Browser-Entwicklertools. Googles Übersicht zu den Core Web Vitals ordnet die Schwellenwerte ein.
Warum ist ein niedriger CLS wichtig?
Springende Layouts sind eines der ärgerlichsten Web-Erlebnisse: Man will auf einen Button tippen, der Inhalt verschiebt sich im letzten Moment — und man landet auf einer Werbeanzeige oder einem falschen Link. Solche Fehlklicks frustrieren Besucher, erhöhen die Absprungrate und können ungewollte Aktionen auslösen, etwa in Formularen oder Bestellstrecken.
Als Teil der Core Web Vitals fließt der CLS außerdem als Signal in die Google-Suche ein und ist damit ein Ranking-Faktor im Bereich des technischen SEO. Für Websites mit Conversion-Zielen — vom Kontaktformular einer Kanzlei bis zum Online-Shop — ist visuelle Stabilität zudem direkt umsatzrelevant, weil sie das Vertrauen und die Bedienbarkeit im entscheidenden Moment betrifft. Der übergreifende Rahmen dafür ist die Web-Performance-Optimierung.
Typische Ursachen und Lösungen für Layout Shifts
Die häufigste Ursache sind Bilder und Videos ohne festgelegte Abmessungen: Der Browser weiß beim Rendern nicht, wie viel Platz er reservieren muss, und schiebt den Inhalt nach, sobald die Datei geladen ist. Die Lösung sind explizite Breiten- und Höhenangaben oder CSS-Seitenverhältnisse. Gleiches gilt für eingebettete Inhalte wie Karten, Videos und Werbeflächen — auch für sie sollte fester Platz reserviert werden. Techniken wie Lazy Loading und moderne Bildformate helfen zusätzlich, ohne neue Sprünge zu erzeugen.
Weitere Verursacher sind nachträglich eingespielte Banner — Cookie-Banner, Aktionsleisten —, die Inhalte verdrängen statt zu überlagern, sowie Webfonts, deren spätes Laden Textumbrüche verändert. Abhilfe schaffen reservierte Bereiche, überlagernde statt schiebende Banner und eine Font-Ladestrategie mit passender Fallback-Schrift. Nach jeder Änderung sollte der Wert erneut mit Felddaten geprüft werden, da Labortests dynamische Inhalte oft nicht erfassen.
CLS messen und dauerhaft überwachen
Zur Messung stehen mehrere Werkzeuge bereit, die sich ergänzen: PageSpeed Insights und die Browser-Entwicklertools liefern Labordaten für einzelne Seiten, die Google Search Console zeigt aggregierte Felddaten über die gesamte Website. Weil CLS auf mobilen Geräten oft schlechter ausfällt als auf dem Desktop — kleinere Bildschirme reagieren empfindlicher auf Verschiebungen —, lohnt der Blick besonders auf die mobile Ansicht im Sinne von Mobile First.
Wichtig ist, den Wert nicht nur einmalig zu prüfen, sondern dauerhaft zu überwachen. Neue Inhalte, eingebundene Werbung oder ein geändertes Cookie-Banner können den CLS jederzeit verschlechtern, ohne dass es sofort auffällt. Ein sauberes Responsive Design mit von vornherein reservierten Flächen ist der wirksamste vorbeugende Schutz, weil es Layout-Sprünge gar nicht erst entstehen lässt.
CLS im Kontext der Web Vitals
CLS ist kein isolierter Wert, sondern Teil eines Systems: Erst zusammen mit LCP (Ladegeschwindigkeit) und INP (Reaktionsfähigkeit) ergibt sich ein vollständiges Bild der Nutzererfahrung. Wer nur den CLS optimiert, aber lange Ladezeiten oder träge Reaktionen ignoriert, verbessert das Erlebnis nur teilweise. Metas übergreifende Empfehlungen fasst Googles Vitals-Leitfaden zusammen.
Wichtig ist die Unterscheidung von Labor- und Felddaten: Werkzeuge wie Lighthouse simulieren einen einzelnen Seitenaufruf, während Google für das Ranking die realen Erfahrungen vieler Nutzer heranzieht. Gerade dynamische Inhalte und Consent-Banner wirken sich im Feld anders aus als im Labor — deshalb ist die Kontrolle über echte Nutzerdaten in der Search Console entscheidend.
CLS bei modernen Websites
Besondere Aufmerksamkeit verlangen dynamisch aufgebaute Seiten. Eine Single-Page-Application, die Inhalte per JavaScript nachlädt und austauscht, kann Layout-Sprünge auch nach dem ersten Laden auslösen — etwa wenn Inhalte beim Weiterscrollen oder nach einer Interaktion eingefügt werden. Hier zahlt sich aus, Platz für erwartete Inhalte von vornherein zu reservieren, statt ihn erst beim Eintreffen der Daten zu schaffen.
Auch personalisierte Elemente, A/B-Test-Varianten und nachgeladene Empfehlungen sind typische Auslöser, weil sie erst nach dem initialen Rendern erscheinen. Der Grundsatz bleibt in allen Fällen derselbe: Wer weiß, dass ein Element kommen wird, sollte ihm seinen Platz zuweisen, bevor es da ist. So bleibt die visuelle Stabilität auch bei komplexen, interaktiven Websites erhalten.