Zum Inhalt springen

5 Min. Lesezeit · 10. Februar 2026

CLS vermeiden: Layout-Shifts eliminieren

Warum Elemente springen und wie Sie Cumulative Layout Shift auf null bringen.

  • Performance
  • CLS

Kennen Sie das? Sie tippen auf einen Link, und plötzlich springt der Inhalt nach unten, weil ein Banner nachgeladen wird. Oder ein Bild erscheint und verschiebt den Text, den Sie gerade lesen wollten. Cumulative Layout Shift (CLS) quantifiziert genau diese frustrierenden Erfahrungen — und Google bewertet sie als Core Web Vital.

Der Zielwert liegt unter 0,1. Für Praxiswebsites, die Vertrauen und Professionalität vermitteln sollen, ist visuelle Stabilität nicht nur eine Kennzahl, sondern ein Qualitätsmerkmal. Springende Layouts wirken unseriös — ein besonderes Problem im Gesundheitskontext.

Wie CLS berechnet wird

CLS summiert alle unerwarteten Layoutverschiebungen während der Lebensdauer einer Seite. Nicht jede Bewegung zählt: Nutzerinitiierte Verschiebungen — etwa durch Klick auf ein Akkordeon — fließen nicht ein. Es zählen nur Verschiebungen, die der Nutzer nicht ausgelöst hat.

Jede Verschiebung wird mit zwei Faktoren gewichtet: Impact Fraction (wie viel des Viewports betroffen ist) und Distance Fraction (wie weit sich Elemente verschoben haben). Ein kleines Element, das weit springt, kann schlimmer sein als ein großes Element mit minimaler Verschiebung.

CLS wird über die gesamte Seitenlebensdauer gemessen, nicht nur beim initialen Laden. Das bedeutet: Ein Cookie-Banner, das nach drei Sekunden erscheint und den Inhalt verschiebt, verschlechtert CLS genauso wie ein Bild ohne feste Abmessungen beim ersten Laden.

Bilder und Medien: Die häufigste CLS-Quelle

Bilder ohne width- und height-Attribute sind der Klassiker. Der Browser kennt die Abmessungen nicht, reserviert keinen Platz und verschiebt den umgebenden Inhalt, sobald das Bild geladen ist.

Lösung: Immer explizite width und height setzen — auch bei responsivem Design. CSS aspect-ratio ergänzt die fluid Skalierung: Das Bild skaliert proportional, aber der Platz ist von Anfang an reserviert. Bei Praxiswebsites betrifft das Teamfotos, Praxisbilder, Behandlungsillustrationen und Blog-Titelbilder.

Videos und iframes — eingebettete Google Maps, YouTube-Erklärvideos, Buchungswidgets — brauchen ebenfalls reservierten Platz. Ein iframe ohne feste Höhe ist einer der häufigsten CLS-Verursacher auf Kontaktseiten.

Responsive Bilder mit srcset ändern nichts an der Notwendigkeit fester Abmessungen. Das srcset bestimmt, welche Datei geladen wird — nicht, wie viel Platz reserviert wird.

Webfonts und der unsichtbare Text

Wenn eine Webfont geladen wird, kann der Text zunächst unsichtbar (FOIT) oder in einer Fallback-Schrift erscheinen (FOUT). Wechselt die Schrift nach dem Laden, ändert sich die Textgröße — und umliegende Elemente springen.

font-display: swap verhindert unsichtbaren Text, löst aber FOUT und potenzielle CLS aus. Die bessere Lösung: size-adjust im @font-face, um die Fallback-Schrift metrisch an die Webfont anzugleichen. Tools wie @napi-rs/wasm-woff oder fontaine (für Astro-Projekte) automatisieren diesen Prozess.

Für Praxiswebsites mit Markenfonts ist der Aufwand lohnenswert. Eine Überschrift, die nach dem Font-Laden 4 Pixel höher wird, verschiebt alles darunter — Hero-Bereich, Call-to-Action-Button, Navigation.

Preload für kritische Fonts (link rel=“preload” as=“font”) beschleunigt das Laden und reduziert das Zeitfenster, in dem Fallback und Webfont wechseln.

Dynamisch nachgeladene Elemente

Cookie-Consent-Banner, Newsletter-Popups, Chat-Widgets, Ankündigungsleisten und Werbebanner erscheinen häufig verzögert und schieben den Hauptinhalt. Auf Praxiswebsites sind Cookie-Banner und gelegentlich Notfall-Hinweise (Urlaubszeiten, neue Öffnungszeiten) die häufigsten dynamischen Elemente.

Lösungsansätze: Overlays statt Inline-Elemente. Ein Cookie-Banner, das als fixed-positioniertes Overlay am unteren Rand erscheint, verschiebt keinen Inhalt. Fest reservierter Platz: Wenn das Banner inline erscheinen muss, Container-Höhe im Voraus definieren. Verzögertes Einblenden erst nach LCP, um zumindest den initialen CLS-Wert nicht zu beeinträchtigen — aber Achtung: CLS wird über die gesamte Lebensdauer gemessen.

Für Ankündigungsleisten empfiehlt sich ein dedizierter Banner-Slot im Layout mit fester Mindesthöhe. Wenn keine Ankündigung aktiv ist, bleibt der Slot leer, aber die Höhe ist reserviert.

AJAX-Inhalte und Skeleton Screens

Leistungsbeschreibungen, die per JavaScript nachgeladen werden, Teamprofile aus einem CMS oder dynamische Öffnungszeiten — alles, was den DOM nach dem initialen Render verändert, kann CLS verursachen.

Skeleton Screens: Platzhalter mit exakt den Abmessungen des späteren Inhalts. Ein grauer Block mit der Höhe des Teamfotos, der durch das echte Bild ersetzt wird, verursacht keinen Layout Shift, wenn die Abmessungen übereinstimmen.

Bei statisch generierten Praxiswebsites ist dieses Problem seltener, weil der Inhalt im HTML enthalten ist und nicht per AJAX nachgeladen wird. Ein weiterer Vorteil des Static-Site-Ansatzes für CLS.

CSS-Animationen und transform statt layout

Animationen, die top, left, width, height oder margin verändern, lösen Layout-Neuberechnungen aus und können CLS erzeugen. Animationen mit transform und opacity sind sicher, weil sie keine Layout-Änderungen verursachen.

Für Praxiswebsites mit dezenten Hover-Effekten auf Buttons und Karten: transform: scale() statt width-Änderungen. Fade-In-Effekte mit opacity statt height-Animationen für Akkordeons — oder das native details/summary-Element nutzen, das der Browser ohne JavaScript-Layout-Manipulation handhabt.

CLS in der Entwicklung testen

Chrome DevTools → Performance: Layout Shift Events werden im Experience-Track markiert. Jeder Shift zeigt betroffene Elemente und den Shift-Score. Lighthouse listet CLS-Verursacher mit Screenshots auf.

Layout Shift Regions in DevTools (Rendering-Tab → Layout Shift Regions) highlighten springende Bereiche in Echtzeit während des Surfens. Besonders hilfreich beim Testen von Cookie-Bannern und dynamischen Inhalten.

WebPageTest bietet filmstrip-basierte CLS-Analyse mit Frame-für-Frame-Vergleich. Für Praxiswebsites empfiehlt sich ein Test mit aktiviertem Cookie-Banner, weil dieser in Labortests oft deaktiviert ist, aber in der Realität CLS verursacht.

Checkliste: CLS vermeiden

  • Allen Bildern width, height und aspect-ratio setzen
  • iframes und Videos mit festen Abmessungen einbetten
  • Webfonts mit size-adjust und font-display: swap optimieren
  • Cookie-Banner als Overlay, nicht als Inline-Element implementieren
  • Platzhalter für dynamisch nachgeladene Inhalte definieren
  • Keine Layout-Animationen — transform und opacity nutzen
  • Ankündigungsleisten mit reserviertem Platz im Layout
  • CLS mit aktiviertem Cookie-Banner und allen Widgets testen
  • Felddaten in PageSpeed Insights über 28 Tage beobachten

Fazit

CLS ist einer der am einfachsten zu behebenden Core Web Vitals — die meisten Ursachen lassen sich mit festen Abmessungen, durchdachtem Font-Loading und Overlay-basierten Bannern eliminieren. Für Praxiswebsites, die Professionalität und Vertrauen vermitteln sollen, ist ein stabiles Layout keine technische Spielerei, sondern Teil der Patientenerfahrung. Bei Monoworks testen wir Layout-Stabilität bei jedem Launch unter realistischen Bedingungen — mit Cookie-Banner, eingebetteten Karten und allen Widgets, die im Produktivbetrieb aktiv sind.