Cumulative Layout Shift (CLS) Probleme identifizieren & beheben

Bevor Sie etwas ändern, bestätigen Sie, dass Sie tatsächlich ein CLS-Problem haben. Loggen Sie sich in die Google Search Console ein, navigieren Sie zu Core Web Vitals und prüfen Sie sowohl Mobile als auch Desktop.

Wenn Google URLs mit "CLS issue: more than 0.25" oder "CLS issue: more than 0.1" markiert, haben Sie die Bestätigung aus dem Chrome User Experience (CrUX) Report, dass echte Nutzer Layoutverschiebungen auf Ihrer Website erleben.

Im Gegensatz zu LCP und INP, wo rohe Rechenleistung und Netzwerkgeschwindigkeit zählen, können CLS-Probleme geräte- oder bildschirmspezifisch sein. Wenn ein ähnliches Problem Mobile und Desktop betrifft (nicht dimensionierte Bilder, Schriftart-Swaps, injizierter Inhalt), könnte Desktop aufgrund der Bildschirmgröße einen weitaus größeren CLS-Wert melden (da ein größerer Teil des sichtbaren Viewports betroffen sein kann). Die Search Console gruppiert URLs zusammen, sodass sie Ihnen sagt, welche Seitentypen betroffen sind, aber nicht, welche Elemente sich verschieben. Dafür benötigen Sie RUM.

Die Search Console bestätigt die Existenz des Problems, gibt Ihnen aber fast nichts, womit Sie arbeiten können. Sie müssen herausfinden, welche Elemente sich verschieben, auf welchen Seiten und unter welchen Bedingungen. Dafür brauchen Sie ein RUM-Tool.

Ich habe CoreDash entwickelt, um genau diese Fragen zu beantworten. Sie fügen ein Script-Tag hinzu und es beginnt damit, CLS-Attributionsdaten von jedem echten Besucher zu sammeln. Der wichtigste Datenpunkt für das CLS-Debugging ist das sich verschiebende Element: der tatsächliche DOM-Knoten, der sich bewegt hat. Ohne diese Information debuggen Sie blind.

Sich verschiebende Elemente finden

Beginnen Sie damit, Ihre nach Element gruppierten CLS-Daten zu betrachten. Navigieren Sie in CoreDash zur CLS-Seite und sehen Sie sich die Datentabelle sortiert nach "CLS by Element" an. Dies zeigt, welche Elemente die meisten Layoutverschiebungen bei all Ihren Besuchern verursachen. Klicken Sie auf das schlimmste Element, um alle Metriken für Seiten zu filtern, auf denen sich dieses Element verschoben hat.

Betroffene Seiten finden

Nachdem Sie nach dem sich am stärksten verschiebenden Element gefiltert haben, überprüfen Sie die URL-Aufschlüsselung. CLS-Probleme können site-weit oder template-weit sein. Jetzt wissen wir, ob sich CLS auf bestimmte Seitentypen konzentriert: Produktseiten mit Bildergalerien, Blog-Posts mit Anzeigenplätzen oder Landing-Pages mit Hero-Animationen. Zu wissen, welche Seiten fehlschlagen, sagt Ihnen, worauf Sie sich konzentrieren müssen.

Neue Besucher vs. wiederkehrende Besucher prüfen

Dies ist eine weitere schnelle Prüfung, die ich durchführe und die mehr Bedeutung hat, als die meisten Leute denken. Font-Swap-CLS tritt nur auf, wenn die Schriftart nicht zwischengespeichert ist. Bilder-CLS von width: auto passiert nur, wenn sich das Bild nicht im Browser-Cache befindet. Wenn Ihr CLS bei Erstbesuchern viel schlechter ist, haben Sie es mit einer cache-abhängigen Verschiebung zu tun, die Sie als Entwickler auf Ihrem eigenen Rechner nie sehen werden, es sei denn, Sie deaktivieren den Cache (Tipp: Deaktivieren Sie immer Ihren Chrome-Cache ... aber das ist eine andere Geschichte für einen anderen Tag).

Gerätetypen und Viewport-Größen prüfen

CLS zeigt typischerweise ein anderes Mobile/Desktop-Muster als LCP und INP. Responsive Layouts können Verschiebungen einführen, die nur bei bestimmten Viewport-Breiten und -Höhen auftreten. Ein Anzeigenplatz, der auf dem Desktop Probleme verursachte, befindet sich auf Mobilgeräten möglicherweise nicht einmal im sichtbaren Viewport. Ein Navigationsmenü könnte bei kleineren Breakpoints anders animiert werden. Gruppieren Sie Ihre CLS-Daten nach Gerätetyp, um zu wissen, wo sie auftreten.

Ihre RUM-Daten haben Ihnen gesagt, welche Elemente sich verschieben und warum. Nun reproduzieren Sie das Problem lokal und finden Sie heraus, was es verursacht.

Den Core Web Vitals Visualizer verwenden

Der schnellste Weg, Layoutverschiebungen zu sehen, ist mit der Core Web Vitals Visualizer Chrome-Erweiterung. Laden Sie die Seite, klicken Sie auf das Erweiterungssymbol und laden Sie neu. Jede Layoutverschiebung wird mit einem farbigen Overlay hervorgehoben, das genau zeigt, was sich bewegt hat und um wie viel. Ich verwende dies als meinen ersten Schritt, bevor ich das Performance-Panel öffne, da es eine sofortige visuelle Antwort liefert.

Die Bedingungen in Chrome nachbilden und die Netzwerk-Screenshots prüfen

CLS-Probleme sind mit einem aufgewärmten Cache oft unsichtbar. Öffnen Sie die DevTools, deaktivieren Sie den Cache im Network-Tab und drosseln Sie die Verbindung auf "Slow 4G" (mein Favorit, er zeigt Ihnen CLS, der durch Race Conditions verursacht wird). Klicken Sie nun auf das Zahnradsymbol und deaktivieren Sie das Caching (während die DevTools geöffnet sind). Dies simuliert die Bedingungen, die Ihre Erstbesucher erleben. Gehen Sie zum Network-Tab und aktivieren Sie Screenshots. Laden Sie nun die Seite neu und achten Sie auf Verschiebungen.

Das Chrome Performance-Panel verwenden

Die meisten Layoutverschiebungen sind leicht zu erkennen, wenn man weiß, wie, aber manchmal werden sie sich Ihnen entziehen. Das ist der Zeitpunkt, die Chrome DevTools (Strg+Shift+I) zu öffnen und für detailliertes Debugging zum Performance-Panel zu gehen. Drücken Sie Strg+Shift+E, um neu zu laden und aufzuzeichnen. Nachdem die Seite geladen ist, scrollen Sie ein paar Mal hoch und runter. Stoppen Sie die Aufzeichnung.

Suchen Sie nach dem Track "Layout Shifts". Jede Verschiebung erscheint als farbiger Block. Klicken Sie auf eine Verschiebung, um Folgendes zu sehen:

• Den sich verschiebenden Knoten: das DOM-Element, das sich bewegt hat
• Den Shift Score: Impact Fraction multipliziert mit Distance Fraction
• hadRecentInput: ob der Verschiebung eine Nutzereingabe vorausging (Klicks und Tipps erhalten eine 500ms Kulanzfrist, aber Scrollen nicht)

Achten Sie darauf, wann die Verschiebungen passieren. Verschiebungen während des Seitenladens deuten auf nicht dimensionierte Bilder, Schriftart-Swaps oder CSS-Transitions hin. Verschiebungen während des Scrollens deuten auf Scroll-ausgelöste Animationen unter Verwendung von Layout-Eigenschaften hin.

Schneller Test: alle Transitions deaktivieren

CSS-Transitions, die Layout-Eigenschaften animieren, sind eine hinterhältige CLS-Ursache, weil sie sich nur während der Ladephase verschieben und schwer zu reproduzieren sind. Fügen Sie dieses Snippet in die Konsole ein, führen Sie einen Hard-Reload der Seite mit deaktiviertem Cache durch und vergleichen Sie den CLS:

document.head.insertAdjacentHTML('beforeend',
  '<style>*{transition-property:none!important}</style>');

Wenn Ihr CLS nach dem Deaktivieren von Transitions sinkt, haben Sie die Ursache gefunden. Verwenden Sie den Leitfaden zum Debuggen von CSS-Transitions, um die spezifischen verantwortlichen Transitions zu finden.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log('Layout shift:', {
        value: entry.value,
        sources: entry.sources?.map(s => ({
          node: s.node,
          previousRect: s.previousRect,
          currentRect: s.currentRect
        }))
      });
    }
  }
});
observer.observe({ type: 'layout-shift', buffered: true });

Sie wissen, welche Elemente sich verschieben und warum. Zeit, sie zu beheben. CLS hat keine sequenziellen Phasen wie LCP. Stattdessen haben Layoutverschiebungen verschiedene Ursachenkategorien. Hier sind die häufigsten, in der Reihenfolge, in der ich ihnen bei Audits begegne.

1. Bilder, Videos und Iframes ohne Dimensionen

Dies ist die häufigste Ursache für CLS im Web. Der 2025 Web Almanac berichtet, dass 62% der mobilen Seiten mindestens ein nicht dimensioniertes Bild haben. Der Fix: Fügen Sie immer width- und height-Attribute zu <img>-, <video>- und <iframe>-Tags hinzu.

<img src="hero.jpg" width="800" height="450" alt="Description">

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

Achten Sie auf width: auto in Ihrem CSS. Diese einzelne Deklaration überschreibt die Seitenverhältnis-Berechnung des Browsers und verursacht Layoutverschiebungen, selbst wenn Sie Breite und Höhe im HTML festgelegt haben. Ich habe das auf dutzenden Seiten gesehen. Der Entwickler hat im Markup alles richtig gemacht, aber eine globale CSS-Regel wie img { width: auto; height: auto; max-width: 100%; } hat alles wieder zunichte gemacht. Für die vollständige Erklärung, siehe Layoutverschiebung verursacht durch Auto-Sizing von Bildern beheben. Für einen vollständigen Leitfaden, der alle Bild- und Medien-CLS-Ursachen abdeckt (Videos, Iframes, Art Direction, responsive Bilder, Lazy Loading, Platzhalter), siehe Wie Bilder und Medien Layoutverschiebungen verursachen.

2. Web Font Swaps

Wenn eine Web-Schriftart geladen wird und die Fallback-Schriftart ersetzt, verursacht der Größenunterschied eine Layoutverschiebung. Der 2025 Web Almanac zeigt, dass nur 11% der Seiten Web-Schriftarten vorladen. Das bedeutet, dass die überwiegende Mehrheit der Websites anfällig für Font-Swap-CLS ist.

Der Fix besteht aus zwei Teilen. Erstens, passen Sie die Fallback-Schriftart mit Metrik-Overrides an die Dimensionen der Web-Schriftart an:

<style>
@font-face {
    font-family: 'My Font Fallback';
    src: local('Arial');
    size-adjust: 105.2%;
    ascent-override: 93%;
    descent-override: 24%;
    line-gap-override: 0%;
}

@font-face {
    font-family: 'My Font';
    src: url('/fonts/myfont.woff2') format('woff2');
    font-display: swap;
}

body {
    font-family: 'My Font', 'My Font Fallback', sans-serif;
}
</style>

Verwenden Sie einen Fallback Font Generator, um die korrekten Override-Werte für Ihr Schriftartenpaar zu berechnen. Zweitens, beschleunigen Sie die Auslieferung: Hosten Sie Ihre Schriftarten selbst, laden Sie Ihre kritische Schriftartendatei vor und verwenden Sie WOFF2 mit Subsetting. Für eine vollständige Strategie, siehe Responsive Web Font Loading und Sicherstellen, dass Text während des Ladens der Web-Schriftart sichtbar bleibt.

3. CSS Animationen und Transitions

Laut dem 2025 Web Almanac führen 40% der mobilen Seiten nicht-kompositierte Animationen aus. Diese animieren Eigenschaften wie width, height, top, left, margin und padding, was eine Layout-Neuberechnung in jedem Frame auslöst.

Der häufigste Übeltäter ist transition: all. Wenn ein Entwickler transition: all .3s ease schreibt, wird jede Eigenschaftsänderung animiert, einschließlich der Layout-Eigenschaften. Während des Seitenladens erzeugen Elemente, die von ihrem ungestylten in den gestylten Zustand übergehen, Layoutverschiebungen, die intermittierend auftreten und fast unmöglich konsistent zu reproduzieren sind. Ich sehe dieses Muster ständig.

Der Fix: Ersetzen Sie Layout-auslösende Eigenschaften durch kompositierte Eigenschaften.

• Verwenden Sie transform: translateY() anstelle von top/bottom
• Verwenden Sie transform: translateX() anstelle von left/right
• Verwenden Sie transform: scale() anstelle von width/height
• Verwenden Sie opacity anstelle von visibility kombiniert mit Höhenänderungen
• Verwenden Sie niemals transition: all. Spezifizieren Sie die genaue Eigenschaft: transition: background-color .2s ease

transform und opacity laufen vollständig im Compositor-Thread und lösen niemals das Layout aus. Für den vollständigen Debugging-Prozess, siehe Layoutverschiebung verursacht durch CSS-Transitions.

4. Anzeigen, Embeds und dynamisch injizierter Inhalt

Anzeigen laden spät und drücken Inhalte nach unten. Cookie-Consent-Banner erscheinen und verschieben die Seite. AJAX-Anfragen injizieren neue Inhalte, ohne zuerst Platz zu reservieren. Das ist alles das gleiche Problem: Etwas erscheint auf der Seite, von dem der Browser zum Zeitpunkt des Renderns nichts wusste.

Der Fix für all dies ist das Reservieren von Platz. Setzen Sie für Anzeigenplätze eine min-height, die der erwarteten Anzeigengröße entspricht:

<style>
.ad-slot {
    min-height: 250px;
    contain: layout style;
}
@media (min-width: 600px) {
    .ad-slot { min-height: 90px; }
}
</style>

Die contain: layout style-Deklaration isoliert den Anzeigencontainer vom Rest der Seite. Verwenden Sie für Cookie-Banner position: fixed zum Überlagern, anstatt Inhalte nach unten zu drücken. Für AJAX-Inhalte reservieren Sie Platz mit min-height. Sie brauchen keine exakte Schätzung: Eine Abweichung von 50px verursacht weit weniger CLS als eine Verschiebung um 400px durch gar keine Reservierung.

Für Third-Party-Embeds wie YouTube, Google Maps und Chat-Widgets verwenden Sie das Facade-Muster: Zeigen Sie einen statischen Platzhalter an und laden Sie das echte Embed erst, wenn der Benutzer damit interagiert. Null CLS, null verschwendete Ressourcen.

5. Scroll-ausgelöste Layoutverschiebungen

Dies ist die CLS-Ursache, die Lighthouse niemals erfassen wird. Lighthouse scrollt die Seite nicht, daher sind Scroll-ausgelöste Layoutverschiebungen in Lab-Tests völlig unsichtbar. Die einzige Möglichkeit, sie zu finden, besteht in RUM-Daten oder der Aufzeichnung eines Performance-Panel-Traces während des manuellen Scrollens.

Das häufigste Beispiel ist ein Hide-on-Scroll-Header, der die Eigenschaft top animiert. Hier ist die Sache, die die meisten Entwickler nicht wissen: Scrollen ist keine ausschließende Eingabe in der Layout Instability-Spezifikation. Klicks und Tipps erhalten eine Kulanzfrist von 500ms. Scrollen nicht. Jede Layoutverschiebung, die durch Scrollen ausgelöst wird, zählt für Ihren CLS-Wert.

Der Fix: Verwenden Sie transform: translateY() anstelle von top für jede Scroll-ausgelöste Animation. Dasselbe gilt für Parallax-Effekte, schrumpfende Navigationsleisten und Scroll-gekoppelte Fortschrittsbalken. Wenn es sich beim Scrollen bewegt, animieren Sie es mit transform. Für den vollständigen Walkthrough mit Videobeispielen, siehe wie Scroll-ausgelöste Animationen CLS verursachen.