Slider im Kopfbereich: warum das Karussell den LCP kostet

Der Largest Contentful Paint misst, wann das größte sichtbare Text- oder Bildelement im ersten Sichtbereich gezeichnet ist. Als gut gilt ein Wert von 2,5 Sekunden (web.dev) oder weniger, gemessen am 75. Perzentil (web.dev) der Seitenaufrufe, getrennt nach Mobil und Desktop. Ein Kopfkarussell ist für diese Messung ein naheliegender Kandidat: Es spannt meist über die volle Breite, trägt ein großformatiges Foto und steht ganz oben. Entsprechend dominieren Bilder das Feld. Laut Web Almanac ist auf 85,3 Prozent (HTTP Archive Web Almanac 2025) der Desktop-Seiten und auf 76 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten ein Bild das LCP-Element. Gleichzeitig erreichen auf dem Smartphone nur 62 Prozent (HTTP Archive Web Almanac 2025) der Websites einen guten LCP. Wer seine Core Web Vitals verbessern will, landet bei Startseiten mit Slider deshalb in der Regel beim Karussell.

Welche Folie gewertet wird, hängt vom Verhalten des Karussells ab. Der Browser meldet während des Ladens laufend neue Kandidaten, sobald ein größeres Element gezeichnet wird, und hört damit bei der ersten Eingabe auf – einem Tippen, einem Scrollen oder einem Tastendruck. Bei einem Karussell, das stillsteht, bis jemand klickt, ist deshalb nur die erste Folie ein möglicher Kandidat. Bei Autoplay dagegen kann jede Folie zum LCP-Element werden, die vor der ersten Eingabe erscheint und größer ist als ihre Vorgängerinnen; bei gleich großen Bildern bleibt es bei der zuerst gezeichneten. Seit Chrome 88 (web.dev) zählen dabei auch Bilder, die später wieder aus dem DOM entfernt werden. Ein Karussell, das beim Weiterschalten die alte Folie austauscht, verliert seinen frühen Kandidaten also nicht mehr – vorher löste jedes Entfernen eine neue LCP-Meldung aus.

Der zweite Stolperstein liegt in den Bilddateien. Viele Karussells werden über Jahre befüllt: Die erste Folie stammt aus einem Fotoshooting in hoher Auflösung, die dritte aus einer Aktion mit kleinerem Format, die fünfte ist ein Ausschnitt aus einem Produktbild. Auf dem Bildschirm skaliert das Karussell alle auf dieselbe Fläche, für den LCP zählt aber der kleinere Wert aus sichtbarer und intrinsischer Größe. Sind die Dateien kleiner als die Anzeigefläche, gewinnt bei Autoplay die Folie mit der größten Datei – und die kommt oft erst als zweite oder dritte an die Reihe. Der Messpunkt rückt damit um einen oder zwei Folienwechsel nach hinten, obwohl die erste Folie längst schnell geladen war. web.dev empfiehlt deshalb ausdrücklich, allen Folien eines automatisch laufenden Karussells dieselbe intrinsische Größe zu geben.

Dazu gehören feste Abmessungen. Fehlen width und height am Bild oder eine reservierte Fläche am Container, springt das Layout, sobald die erste Folie eintrifft, und der Inhalt darunter rutscht nach unten. Laut Web Almanac setzen 65 Prozent (HTTP Archive Web Almanac 2025) der Desktop-Seiten bei mindestens einem Bild keine festen Maße. Für das Karussell heißt das: eine einheitliche Bildvorlage mit festem Seitenverhältnis, Varianten per srcset in mehreren Breiten und ein modernes Format. Wie die Formatwahl die Dateigröße bei gleicher Qualität drückt, steht im Beitrag zu WebP und AVIF; die Umstellung ganzer Bildbestände gehört in die Bilder-Optimierung.

Der Cumulative Layout Shift kennt eine Schonfrist für erwartete Bewegungen. Verschiebungen, die innerhalb von 500 Millisekunden (web.dev) nach einer Eingabe stattfinden, werden markiert und aus der Berechnung herausgenommen – wer auf einen Pfeil klickt, erwartet, dass sich etwas bewegt. Für Karussells heißt das: Bei einem Karussell ohne Autoplay fallen die Verschiebungen eines Folienwechsels meist in genau diese 500 Millisekunden (web.dev) und zählen nicht in den CLS. Beim Autoplay fehlt die Eingabe. Jeder Wechsel, den der Zeitgeber auslöst, ist aus Sicht der Messung unerwartet, und jede Verschiebung, die eine Animation über left oder width dabei erzeugt, geht in den Wert ein. Als gut gilt ein CLS von 0,1 (web.dev) oder weniger – eine Grenze, die ein vollflächiger Slider mit schlecht animierten Übergängen schnell überschreiten kann.

web.dev warnt vor diesem Fall mit einer drastischen Formulierung: Seiten mit Autoplay-Karussell könnten einen unbegrenzten CLS erzeugen, und weil diese Verschiebungen mit bloßem Auge kaum auffallen, werden sie leicht übersehen. Seit der Umstellung der Metrik auf Sitzungsfenster ist das etwas zu relativieren. Gewertet wird nicht mehr die Summe aller Verschiebungen über die gesamte Lebensdauer der Seite, sondern das schlimmste Sitzungsfenster: eine Folge von Verschiebungen mit jeweils weniger als 1 Sekunde (web.dev) Abstand, die insgesamt höchstens 5 Sekunden (web.dev) dauert. Ein Autoplay-Karussell addiert sich damit nicht mehr ins Unendliche. Jedes einzelne Fenster kann die Grenze aber überschreiten, und eine gleitende Animation über left, die über viele Einzelbilder hinweg Verschiebungen erzeugt, landet vollständig in einem Fenster. Wer im Shop ohnehin mit Layoutsprüngen kämpft, findet die übrigen Ursachen im Beitrag zum CLS im Online-Shop.

Neben den Messwerten gibt es eine Anforderung, die kein Optimierungsziel ist, sondern eine Pflicht. Erfolgskriterium 2.2.2 der WCAG verlangt für bewegte Inhalte, die automatisch starten, länger als fünf Sekunden (W3C WCAG 2.2) laufen und neben anderem Inhalt stehen, einen Mechanismus zum Anhalten, Stoppen oder Ausblenden. Das Kriterium gehört zur Stufe A, also zur Grundstufe. Das Begleitdokument des W3C begründet die Grenze: Fünf Sekunden (W3C WAI) seien lang genug, um Aufmerksamkeit zu erregen, aber kurz genug, dass man die Ablenkung notfalls abwarten kann. Ein Autoplay-Karussell in Dauerschleife fällt damit in der Regel unter das Kriterium. Wichtig ist eine Feinheit: Als automatisch gestartet gilt auch Bewegung, die durch eine indirekte Handlung beginnt, etwa durch Fokus, Überfahren mit der Maus oder das Hineinscrollen in den sichtbaren Bereich.

Für die Umsetzung beschreibt das Karussell-Tutorial der W3C WAI drei Bausteine. Erstens einen sichtbaren Schalter zum Anhalten und Fortsetzen, dessen Beschriftung sich mit dem Zustand ändert. Zweitens eine Pause, solange der Mauszeiger über dem Karussell liegt oder ein Element darin den Tastaturfokus hat – so verlieren Tastaturnutzer ihre Position nicht, und Links in der Folie lassen sich bequem anklicken. Drittens das Verbergen der gerade wechselnden Folie vor assistiver Technik, damit ein Screenreader nicht zwei Folien zugleich anbietet. Der folgende Ausschnitt setzt das um und nutzt dafür inert, das verborgene Folien zugleich aus der Tastaturreihenfolge nimmt. Wie sich solche Anforderungen in das übrige Frontend einfügen, gehört in jede Prüfung zur Barrierefreiheit.

Vor jeder Umbauentscheidung steht die Messung. Im Feld zeigt der LCP-Eintrag, welches Element gewertet wurde; im Labor lässt sich prüfen, wann die erste Folie angefordert wird und ob beim Folienwechsel Verschiebungen auftreten. Wichtig ist, beide Blickwinkel zu trennen: Ein Laborlauf ohne Eingabe bildet das Autoplay ab, echte Besucher tippen dagegen früher oder später, und ab dann zählen keine neuen LCP-Kandidaten mehr. Eine strukturierte Analyse verbindet beide Sichten. Die folgende Liste deckt die häufigsten Schwachstellen ab.

Wer den Slider nicht selbst zerlegen will: In der Frontend-Optimierung nehmen wir das Karussell als eigenes Bauteil auf, messen, welche Folie im Feld als LCP gewertet wird, und bauen Ladeweg, Übergänge und Pause-Steuerung so um, dass die Werte in der Regel stabil bleiben. Die Einordnung in die übrigen Kennzahlen liefert die Seite zu den Core Web Vitals, die Arbeit an den Bilddateien selbst die Bilder-Optimierung. Für eine erste Einschätzung genügt eine Nachricht über die Kontaktseite.