Der Cumulative Layout Shift (CLS) misst, wie stark sich sichtbare Inhalte einer Seite unerwartet verschieben, während sie geladen wird oder offen ist. Je kleiner der Wert, desto stabiler wirkt die Seite. Der CLS ist eine der drei Core Web Vitals.
Auf einen Blick
- Misst
- größte Folge unerwarteter Layout-Verschiebungen im gesamten Lebenszyklus einer Seite
- Datenquelle
- Feld (CrUX, PageSpeed Insights, Search Console) und Labor (Lighthouse, Chrome DevTools)
- Grenze „gut“
- 0,1 oder weniger
- Bewertung
- 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt
- Core Web Vital
- Ja, eine der drei Core Web Vitals
Stand:
Wie wird CLS berechnet?
Jede einzelne Verschiebung bekommt einen Layout-Shift-Score. Er ergibt sich laut web.dev aus zwei Anteilen:
Score = Impact Fraction × Distance Fraction
Die Impact Fraction beschreibt, welcher Teil des Viewports von den verschobenen Elementen betroffen ist. Die Distance Fraction gibt an, wie weit sich die Elemente bewegen, bezogen auf die größere Viewport-Dimension.
Einzelne Verschiebungen werden zu Session Windows gebündelt. Ein Fenster endet, wenn zwischen zwei Verschiebungen mehr als 1 Sekunde liegt oder das Fenster 5 Sekunden lang ist. Als CLS gilt der Summenwert des schlechtesten Fensters.
Grenzwerte
Bewertet wird das 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt. Quelle: web.dev: Cumulative Layout Shift (CLS). Stand: .
Gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt für Mobilgeräte und Desktop.
| Messwert | Misst | Core Web Vital? | Feld oder Labor | „Gut“ laut web.dev |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Renderzeit des größten sichtbaren Bilds, Textblocks oder Videos im Viewport, ab Beginn der Navigation | ja (Laden) | Feld und Labor | bis 2,5 s |
| INP (Interaction to Next Paint) | Latenz der Interaktionen während des gesamten Besuchs bis zur nächsten Darstellung; ein Wert, unter dem (fast) alle Interaktionen liegen | ja (Interaktivität), seit 12.03.2024 | Feld; im Labor nur mit simulierten Interaktionen, Lighthouse misst INP nicht | bis 200 ms |
| CLS (Cumulative Layout Shift) (dieser Begriff) | größte Folge unerwarteter Layoutverschiebungen während der gesamten Lebensdauer der Seite | ja (visuelle Stabilität) | Feld und Labor | bis 0,1 |
| TTFB (Time to First Byte) | Zeit vom Beginn der Navigation bis zum ersten Byte der Antwort | nein (hilft bei der Diagnose von LCP) | Feld und Labor | bis 0,8 s |
| FCP (First Contentful Paint) | Zeit vom Beginn der Navigation, bis irgendein Inhalt der Seite dargestellt wird | nein (hilft bei der Diagnose von LCP) | Feld und Labor | bis 1,8 s |
| TBT (Total Blocking Time) | Summe der Zeit nach dem FCP, in der der Hauptthread so lange blockiert war, dass Eingaben nicht reagieren konnten | nein (Labor-Stellvertreter für INP) | Labor; Feldmessung empfiehlt web.dev nicht | unter 200 ms auf durchschnittlicher mobiler Hardware |
| Speed Index | wie schnell Inhalte beim Laden sichtbar aufgebaut werden (aus einem Video des Ladevorgangs) | nein | Labor (Lighthouse) | Schwelle laut Lighthouse: mobil bis 3,4 s „schnell“ (web.dev nennt keinen Wert) |
| FID (First Input Delay), historisch | Zeit von der ersten Interaktion bis der Browser mit der Verarbeitung der Event-Handler beginnen kann | bis 12.03.2024, ersetzt durch INP | nur Feld | bis 100 ms |
Bewertet wird laut web.dev das 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt. Eine Seite besteht die Core Web Vitals, wenn LCP, INP und CLS am 75. Perzentil im Bereich „gut“ liegen. Chrome-Tools unterstützen FID seit dem 9. September 2024 nicht mehr. Quellen: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Stand: .
Was nicht zählt
Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzereingabe wie Klick, Tap oder Tastendruck werden ausgeschlossen. Sie sind im Browser mit dem Flag hadRecentInput markiert, denn der Nutzer hat sie selbst ausgelöst.
Typische Ursachen
web.dev nennt vor allem diese Auslöser:
- Bilder und Videos ohne
widthundheight - Web Fonts, die nach dem ersten Rendern die Schrift tauschen
- Anzeigen, Einbettungen und iframes ohne reservierten Platz
- Inhalte, die nachträglich oberhalb von vorhandenem Inhalt eingefügt werden
- Animationen, die Position oder Größe statt
transformändern
web.dev empfiehlt für Animationen transform (zum Beispiel scale oder translate), weil es kein neues Layout auslöst.
Beispiel
<img src="/produkt.jpg" width="800" height="600" alt="Produkt">
Mit den Attributen reserviert der Browser die Fläche, bevor das Bild geladen ist. Der Text darunter springt beim Laden nicht nach unten.
Häufige Fehler
- Nachgeladene Inhalte ohne reservierten Platz. Inhalte, die nach dem ersten Laden erscheinen, etwa beim Scrollen, verschieben den Rest der Seite, wenn kein Platz vorgesehen ist.
- Nur im Labor messen. web.dev weist darauf hin, dass Labortools Verschiebungen beim Laden messen und echte Werte unterschätzen können. Felddaten zeigen, was Nutzer erleben.
Häufige Fragen
Was ist ein guter CLS-Wert? Bis 0,1 am 75. Perzentil.
Wie unterscheiden sich CLS und LCP? Der LCP misst die Ladezeit des größten Elements, der CLS die visuelle Stabilität.
Quellen
Stand: