CLS (Cumulative Layout Shift): Definition & Optimierung (2026)

von

Der Cumulative Layout Shift (CLS) ist eine Kennzahl für die visuelle Stabilität einer Seite. Er quantifiziert, wie stark sich sichtbare Inhalte unerwartet verschieben, etwa wenn Text wegrutscht, weil ein Bild oder eine Anzeige nachlädt.[1] CLS gehört zu den drei Core Web Vitals, mit denen Google die reale Nutzererfahrung misst.[2]

CLS ist ein Signal der Seitenerfahrung, die Belege dazu stehen im Abschnitt Definition und Einordnung.

  • Für Google ist CLS ein bestätigtes Signal, Relevanz geht bei der Platzierung jedoch vor (siehe Wie wichtig ist CLS?).
  • Prüfe CLS zuerst mit Felddaten und nutze Laborwerte zur Fehlersuche (siehe Messung und Diagnose).
  • Häufige Ursachen sind Bilder, Anzeigen, Embeds und Web Fonts ohne reservierten Platz (siehe Fallstricke und Optimierung).

Definition und Einordnung

Was bedeutet CLS genau?

CLS bewertet die Layout Shifts einer Seite. Ein Layout Shift liegt vor, wenn ein sichtbares Element von einem gerenderten Frame (Einzelbild der Darstellung) zum nächsten seine Startposition ändert. Neu eingefügte Elemente und Größenänderungen zählen nur dann, wenn sie andere sichtbare Elemente verschieben.[1]

Der Score einer einzelnen Verschiebung ist das Produkt aus Impact Fraction und Distance Fraction. Die Impact Fraction ist der Anteil des Viewports (sichtbarer Bereich der Seite), den die instabilen Elemente in beiden Frames zusammen belegen, die Distance Fraction die größte Verschiebungsdistanz geteilt durch die längere Viewport-Kante.[1] Füllt ein Element den halben Viewport und rutscht um 25 % der Viewport-Höhe nach unten, beträgt die Impact Fraction 0,75, die Distance Fraction 0,25 und der Score 0,1875.[1]

Für den CLS-Wert werden die unerwarteten Verschiebungen in Session Windows gruppiert: Mehrere Verschiebungen mit weniger als einer Sekunde Abstand und höchstens fünf Sekunden Gesamtdauer bilden ein Fenster. Gewertet wird das Fenster mit der höchsten Summe über die gesamte Lebensdauer der Seite.[1] Browser melden Verschiebungen über die Layout Instability API als layout-shift-Einträge.[1]

Woher ist der Faktor bekannt und wie sicher ist die Evidenz?

Die Grundlage ist Googles offizielle Dokumentation: Google bestätigt, dass seine Rankingsysteme Core Web Vitals nutzen, und empfiehlt gute Werte.[2] [3] Es gibt kein einzelnes Page-Experience-Signal, die Systeme betrachten eine Vielzahl von Signalen, die zur Seitenerfahrung passen.[3]

Google nennt keine Gewichtung von CLS im Ranking und beziffert keinen Ranking-Effekt einer Verbesserung. Die Grenzwerte für gut und schlecht beschreiben eine gute Nutzererfahrung, als Ranking-Grenzwert nennt Google sie nicht.[2]

Auch die Messlogik ist nicht überall gleich dokumentiert. Die Search-Console-Hilfe beschreibt CLS noch als Summe der Scores aller unerwarteten Layout Shifts über die gesamte Lebensdauer der Seite.[4] web.dev wertet das Session Window mit der höchsten Summe und nennt die Summenberechnung ausdrücklich als frühere Definition.[1] Als aktueller Stand gilt deshalb die Definition von web.dev.

Wie wichtig ist CLS?

Welche Rolle spielt CLS im Ranking?

Relevanz geht vor: Google zeigt nach eigener Aussage stets die relevantesten Inhalte, auch wenn die Seitenerfahrung schwach ist. Bei vielen Suchanfragen gibt es jedoch viele hilfreiche Inhalte, und dort kann eine gute Seitenerfahrung zum Erfolg beitragen.[3] Ob CLS-Arbeit den Ausschlag gibt, hängt deshalb von der Konkurrenzlage der jeweiligen Anfrage ab. Die Rankingsysteme bewerten Inhalte grundsätzlich seitenspezifisch, kennen aber auch einzelne seitenweite Einschätzungen.[3]

Typische Missverständnisse

  • „Jede Verschiebung schadet dem CLS.“ Verschiebungen innerhalb von 500 Millisekunden nach einer diskreten Eingabe wie Tippen, Klicken oder Tastendruck werden ausgeschlossen. Scrollen, Ziehen und Zoomen gelten nicht als Eingabe.[1]
  • „Gute Core Web Vitals garantieren eine Top-Platzierung.“ Laut Google garantieren gute Ergebnisse in der Search Console oder in Drittanbieter-Tools keinen Platz an der Spitze, denn eine gute Seitenerfahrung umfasst mehr als die Core-Web-Vitals-Werte.[3]
  • „Nur ein perfekter Score lohnt sich.“ Ein perfekter Score allein aus SEO-Gründen ist laut Google womöglich nicht die beste Verwendung deiner Zeit, die Werte sollen helfen, die Seite insgesamt für Nutzer zu verbessern.[3]
  • „Verschiebungen in eingebetteten iframes zählen nicht.“ Die Layout Instability API meldet Verschiebungen in iframes nicht, die Metrik zählt sie aber, und CrUX enthält sie. Eigene JavaScript-Messungen können daher niedriger liegen als CrUX-Werte, in Cross-Origin-iframes ist die Messung teils gar nicht möglich.[1] [5]

Messung und Diagnose

Selbstaudit: Wo steht deine Seite?

Felddaten stammen aus dem Chrome User Experience Report (CrUX), der anonymisierte Messwerte echter Nutzer sammelt.[4] Bewertet wird das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop.[1] Als gut gilt eine Seite, wenn mindestens 75 Prozent der Aufrufe den Grenzwert für gut einhalten.[6]

Prüfpunkt Grün Gelb Rot Beleg
CLS im Feld, Mobil (75. Perzentil) bis 0,1 über 0,1 bis 0,25 über 0,25 [1] [4]
CLS im Feld, Desktop (75. Perzentil) bis 0,1 über 0,1 bis 0,25 über 0,25 [1] [4]
Feld- und Laborwert in PageSpeed Insights Beide Werte im guten Bereich Laborwert gut, Feldwert schlechter: Die Ursache liegt wahrscheinlich nach dem Laden, etwa bei Inhalten, die beim Scrollen nachladen Feld- und Laborwert beide schlecht: Die Ursache liegt im Ladevorgang, Lighthouse zeigt sie an [5]
Bilder und Videos Alle tragen width und height oder ein aspect-ratio Einzelne Elemente ohne Angaben Die meisten Elemente ohne Angaben [5]
Anzeigen, Embeds, iframes Platz reserviert und bleibt auch ohne ausgelieferten Inhalt erhalten Platz für die kleinste Größe reserviert, größere Inhalte verschieben Folgeinhalte Kein Platz reserviert [5]
Web Fonts Fallback definiert, Metriken angepasst oder font-display: optional, kritische Fonts vorgeladen Fallback definiert, keine Anpassung Kein Fallback definiert [5]
Nachträglich eingefügte Elemente (Banner, Formulare, Hinweise) Platz vorab reserviert oder Overlay außerhalb des Dokumentflusses (normale Anordnung der Elemente) Einfügung weiter unten im Viewport ohne reservierten Platz, sie verschiebt weniger, aber trotzdem Einfügung im oberen Bereich, der Inhalt rutscht nach unten [5]

Die Grenze von 0,1 leitet Google aus internen Tests mit realen Seiten ab: Verschiebungen ab 0,15 wurden durchgehend als störend wahrgenommen, bis 0,1 als spürbar, aber nicht übermäßig störend.[6]

Tools und Datenquellen

Tool Bericht oder Kennzahl Wofür
Search Console Bericht „Core Web Vitals“: Status je URL-Gruppe (Good, Need improvement, Poor) nach der schlechtesten Metrik. Der Gruppen-CLS ist der Wert, den 75 % der Besuche der letzten 28 Tage erreichten oder unterschritten Überblick über Musterseiten und seitenübergreifende Probleme. Nur indexierte URLs, nicht zum Prüfen einer einzelnen URL gedacht [4]
PageSpeed Insights Felddaten (CrUX, letzte 28 Tage) und Labor-Diagnose mit Lighthouse (simulierter Seitenaufruf). Bei zu wenig URL-Daten Rückfall auf die Origin-Ebene (alle Seiten der Website). Das Assessment gilt als bestanden, wenn das 75. Perzentil aller Core Web Vitals gut ist Feld- und Laborwert einer URL vergleichen [7]
Lighthouse Audits zu Bildern ohne width und height sowie zu den beim Laden verschobenen Elementen Ladeprobleme finden. Die gelisteten Elemente sind oft die betroffenen, nicht die verursachenden [5]
Chrome DevTools Performance-Panel mit Live-Metrics-Ansicht, Layout-Shifts-Track und Insight „Layout shift culprits“, dazu die Rendering-Einstellung „Layout Shift Regions“ Verschiebungen nachstellen, Zeitpunkt, Score und betroffene Elemente ansehen [8]
web-vitals-Bibliothek onCLS und Attribution-Funktionen CLS und betroffene Elemente bei echten Nutzern erfassen [1] [5]
Layout Instability API mit PerformanceObserver layout-shift-Einträge mit Score, hadRecentInput und den verschobenen Elementen Debugging in der Konsole, nur in Chromium-Browsern unterstützt. Die gemeldeten Elemente sind verschoben worden, nicht zwingend die Ursache [8]

Optimierung

Die wichtigsten Hebel

  1. Bilder und Videos mit Dimensionen versehen (Quick Win). Setze auf <img>– und <video>-Elementen width und height oder reserviere den Platz per CSS aspect-ratio. Aus den Attributen berechnen Browser vor dem Laden ein Standard-Seitenverhältnis und halten den passenden Platz frei.[5] Bei srcset müssen alle Varianten dasselbe Seitenverhältnis haben, für unterschiedliche Bildausschnitte kannst du width und height auch an den <source>-Elementen eines <picture>-Elements setzen.[5]
  2. Nachträglich eingefügte Elemente kontrollieren (Quick Win). Füge Banner, Formulare und Hinweise nicht ohne Nutzeraktion in den Dokumentfluss ein. Reserviere vorab Platz mit einem Platzhalter (Skeleton-UI) oder überlagere den Inhalt außerhalb des Dokumentflusses, wo das sinnvoll ist.[5] Bei nachgeladenen Listen tauschst du Inhalte in einem Container fester Größe aus, lässt Nutzer das Nachladen per „Load more“ auslösen (Inhalte vorab laden) oder lädst offscreen und blendest einen Hinweis ein.[5]
  3. Animationen auf transform umstellen (Quick Win). Animiere mit transform (translate, scale) statt mit top, left, width oder height. Composited Animationen mit translate beeinflussen andere Elemente nicht und zählen nicht zum CLS, Änderungen an top und left lösen dagegen auch auf einer eigenen Ebene Layout Shifts aus.[5] Berücksichtige dabei prefers-reduced-motion.[1]
  4. Platz für Anzeigen, Embeds und iframes reservieren (Langfristig). Reserviere den Platz per min-height oder aspect-ratio, bei Bedarf je Formfaktor über Media Queries.[5] Lässt sich die Höhe nicht exakt bestimmen, kannst du die kleinste vorkommende Größe reservieren und kleine Verschiebungen bei größeren Inhalten hinnehmen, oder die wahrscheinlichste Größe aus historischen Daten wählen und dafür mehr Leerraum akzeptieren.[5] Lasse den Platz auch stehen, wenn keine Anzeige ausgeliefert wird, denn entfernter Platz erzeugt ebenso CLS wie eingefügter Inhalt. Ist keine Reservierung möglich, platziere den Inhalt weiter unten im Viewport.[5]
  5. Web Fonts entschärfen (Langfristig). Definiere einen passenden Fallback, etwa sans-serif, denn der Browser-Standard ist in Chrome eine Serifenschrift („Times“).[5] Gleiche die Abmessungen von Fallback und Web Font mit size-adjust, ascent-override, descent-override und line-gap-override an und lade kritische Fonts früh per rel="preload", damit sie idealerweise vor dem ersten Paint vorliegen.[5] Mit font-display: optional entsteht kein neues Layout, weil die Schrift nur genutzt wird, wenn sie beim ersten Layout verfügbar ist.[5]
  6. Seiten für den bfcache qualifizieren (Langfristig). Der Back/Forward-Cache (bfcache) hält Seiten nach dem Verlassen kurz im Browser-Speicher und stellt sie beim Zurücknavigieren exakt so wieder her, wie du sie verlassen hast, ohne erneute Verschiebungen.[5] Der Effekt greift bei Zurück- und Vor-Navigationen, etwa zu Kategorie- oder Suchergebnisseiten, und ersetzt keine Korrektur der Verschiebungen beim ersten Aufruf.[5]

Umsetzung in Schritten

  1. Prüfe den Search-Console-Bericht für Mobil und Desktop und beginne mit den URL-Gruppen im Status „Poor“. Priorisiere danach nach der Zahl der betroffenen oder der Wichtigkeit der URLs.[4]
  2. Rufe eine Beispiel-URL in PageSpeed Insights auf und vergleiche Feld- und Laborwert wie im Selbstaudit beschrieben.
  3. Stelle die Verschiebung nach: Interagiere fünf bis zehn Minuten mit der Seite, während die Konsole mit einem PerformanceObserver für layout-shift-Einträge offen ist, und wiederhole das mit anderen Geräten und langsamer Verbindung.[8]
  4. Grenze die Ursache ein: Prüfe das Element direkt vor dem verschobenen Element. Hat es Position oder Größe geändert, wurde davor ein Element eingefügt oder entfernt? Eine große Verschiebung nach unten deutet oft auf ein eingefügtes Element, eine Verschiebung um 1 bis 2 Pixel auf konkurrierende CSS-Regeln oder ein nachgeladenes Web Font.[8]
  5. Setze die passenden Hebel aus der Liste oben um.
  6. Teste typische Nutzerabläufe im Timespan-Modus der Lighthouse-User-Flows, damit neue Verschiebungen auffallen.[5]
  7. Starte nach dem Rollout die Validierung in der Search Console (Details unter Häufige Fragen).

Fallstricke und Grenzen

Typische Fehler

  • Bilder ohne Dimensionen: Der Browser kennt die Größe erst beim Download, und der Text darunter rutscht nach, sobald das Bild geladen ist.[5]
  • Anzeigen, Embeds und iframes ohne Dimensionen: Sie schieben nachfolgende Inhalte nach unten, sobald sie erscheinen.[5]
  • Inhalte oberhalb bestehender Inhalte nachladen, etwa bei Infinite Scroll: Das Einfügen von Elementen gehört zu den häufigen Auslösern von Verschiebungen.[8]
  • Unsichtbaren Text während des Font-Ladens für unproblematisch halten: Auch unsichtbarer Text wird mit der Ersatzschrift gesetzt, beim Laden des Web Fonts verschieben sich Textblock und Umgebung wie bei sichtbarem Text.[5]

Wann stößt CLS an Grenzen?

Bei Inhalten von Drittanbietern hast du wenig Kontrolle: Die genaue Größe des eingefügten Inhalts ist oft unbekannt, und Verschiebungen innerhalb der Einbettung lassen sich nicht steuern.[5] Anzeigen gehören zu den größten Verursachern von Layout Shifts.[5] Google nennt genau solche Fälle, etwa Social-Media-Embeds, deren Höhe erst nach dem Laden feststeht, als Grund, den Grenzwert für gut großzügiger anzusetzen.[6]

Zusammenspiel mit anderen Faktoren

  • LCP: Die Kennzahl misst die Ladeleistung und bildet mit CLS und INP die Core Web Vitals.[2]
  • INP: Die Kennzahl misst die Reaktionsfähigkeit.[2]
  • Werbung und Interstitials: Google fragt in der Selbstbewertung zur Seitenerfahrung, ob eine Seite ohne übermäßige, vom Hauptinhalt ablenkende Werbung und ohne aufdringliche Interstitials auskommt.[3]
  • Mobile Darstellung: Ob Inhalte auf Mobilgeräten gut dargestellt werden, steht in derselben Selbstbewertung.[3]

Häufige Fragen zu CLS

Warum weicht der CLS in PageSpeed Insights von der Search Console ab?

Die Tools aggregieren unterschiedlich. Der Search-Console-Bericht fasst ähnliche URLs zu Gruppen zusammen, PageSpeed Insights zeigt meist Daten einer einzelnen URL, die als Ausreißer von der Gruppe abweichen kann.[4] Außerdem unterscheidet die Search Console Seiten anhand ihrer URL-Parameter, PageSpeed Insights entfernt die Parameter und ordnet alle Ergebnisse der URL ohne Parameter zu.[4]

Warum ändert sich mein CLS-Status, obwohl ich nichts geändert habe?

Liegen viele Seiten knapp an einer Grenze, kann ein kleines seitenweites Ereignis sie in einen anderen Status schieben. Google nennt etwa stark gestiegenen Traffic oder eine geänderte Latenz bei dem Dienst, der deine Bilder ausliefert. Seltener ändern sich Browser, Geräte oder Standorte deiner Nutzer, zum Beispiel durch ein weit verbreitetes Browser-Update. Prüfe deine Logs auf solche Änderungen.[4]

Warum zeigt die Search Console „No data available“?

Meist liegen für den gewählten Gerätetyp nicht genug CrUX-Daten vor. Bei einer neuen Property kann es einige Tage dauern, bis vorhandene Daten erscheinen, und der Bericht zeigt nur indexierte URLs.[4] CrUX verarbeitet zudem nur öffentliche, crawlbare und indexierbare URLs mit genug Stichproben von Nutzern, die der Datenerhebung zugestimmt haben.[7]

Wie lange dauert die Validierung nach einem CLS-Fix?

Die Validierung dauert 28 Tage. Mit „Start Tracking“ beginnt die Search Console einen Beobachtungszeitraum auf Basis der CrUX-Daten, das Problem gilt als behoben, wenn es in diesem Zeitraum auf keiner URL auftritt. „Start Tracking“ löst weder eine Neuindexierung noch eine andere aktive Aktion von Google aus. Schlägt die Validierung fehl, behebst du die Ursache erneut und startest eine neue Validierung.[4]

Fazit

Prüfe CLS zuerst mit Felddaten, grenze die Ursachen im Labor ein und reserviere Platz für Bilder, Anzeigen, Embeds und Schriften. Wie CLS zu den übrigen Signalen passt, zeigt die Übersicht aller Rankingfaktoren Rankingfaktoren. Weitere Webcorevitals: INP und LCP

Quellen

  1. web.dev: Cumulative Layout Shift (CLS) (Stand: 12.04.2023). https://web.dev/articles/cls. Abgerufen am 19.09.2026.
  2. Google Search Central: Understanding Core Web Vitals and Google search results (Stand: 10.12.2025). https://developers.google.com/search/docs/appearance/core-web-vitals. Abgerufen am 19.09.2026.
  3. Google Search Central: Understanding page experience in Google Search results (Stand: 10.12.2025). https://developers.google.com/search/docs/appearance/page-experience. Abgerufen am 19.09.2026.
  4. Search Console Help: Core Web Vitals report. https://support.google.com/webmasters/answer/9205520. Abgerufen am 19.09.2026.
  5. web.dev: Optimize Cumulative Layout Shift (Stand: 07.02.2025). https://web.dev/articles/optimize-cls. Abgerufen am 19.09.2026.
  6. web.dev: How the Core Web Vitals metrics thresholds were defined (Stand: 07.05.2025). https://web.dev/articles/defining-core-web-vitals-thresholds. Abgerufen am 19.09.2026.
  7. Google for Developers: About PageSpeed Insights (Stand: 21.10.2024). https://developers.google.com/speed/docs/insights/v5/about. Abgerufen am 19.09.2026.
  8. web.dev: Debug layout shifts (Stand: 07.02.2025). https://web.dev/articles/debug-layout-shifts. Abgerufen am 19.09.2026.