Visual Stability Index 2026: der nächste CLS-Schritt

CLS wurde als Metrik für die unerwartete Verschiebung sichtbarer Elemente konzipiert. In der Feldmessung erfasst CLS zwar bereits die gesamte Seitenlebensdauer, doch in der Praxis - und besonders in Labortests - dominiert der Ladevorgang das Bild. Ein Headless-Browser lädt die Seite einmal, ohne zu scrollen, ohne Maus, ohne Interaktion, und sieht damit nur die Sprünge der Initialphase (Quelle: DebugBear). Genau hier setzt der Visual Stability Index an: Er bewertet visuelle Stabilität über den kompletten Besuch und fängt damit Verschiebungen ein, die CLS in der gängigen Optimierungspraxis systematisch unterschätzt - etwa beim Scrollen oder bei nachladenden Inhalten (Quelle: Core Web Vitals 2026 Branchenberichte).

Der entscheidende konzeptionelle Unterschied ist die Absichtserkennung. VSI gilt als intent-aware: Bewegungen, die Nutzer selbst auslösen und erwarten - ein aufklappendes Akkordeon, ein Filter, der eine Liste neu sortiert, ein Karussell, das auf Klick weiterblättert - werden in der Regel nicht negativ gewertet. Bestraft werden unerwartete Verschiebungen, etwa spät eingeblendete Banner, verzögert geladene Anzeigen, einrastende Sticky-Elemente oder dynamisch injizierte Inhalte (Quelle: Core Web Vitals 2026 Branchenberichte). Damit verschiebt sich die Optimierung weg von der reinen Ladephase hin zur Frage: Bleibt das Layout auch dann ruhig, wenn der Nutzer es benutzt?

Wichtig für die Einordnung: VSI gilt derzeit als aufkommendes Signal, nicht als primärer Rankingfaktor wie LCP, INP oder CLS. Branchenberichte gehen davon aus, dass Google bereits über den Chrome User Experience Report Daten sammelt und VSI dem Muster früherer Core-Web-Vitals-Einführungen folgend binnen 12 bis 18 Monaten zu einem primären Faktor werden könnte (Quelle: Core Web Vitals 2026 Branchenberichte). Diese Vorlaufzeit ist der eigentliche Hebel - wer jetzt stabilisiert, sammelt saubere Felddaten, bevor der Faktor scharf geschaltet wird.

Die bisherige CLS-Praxis konzentriert sich auf den sichtbaren Bereich beim Erstaufbau: Bilder oberhalb der Falz bekommen Maße, der Hero-Bereich wird stabilisiert, Web-Fonts werden vorgeladen. Das ist richtig und bleibt die Basis. Doch sobald der Nutzer scrollt, beginnt ein Bereich, den Labortests in der Regel gar nicht betreten. Kontinuierliche Interaktionen wie Scrollen, Ziehen oder Zoomen gelten ausdrücklich nicht als jüngste Eingabe im Sinne des Recent-Input-Fensters - jede Verschiebung während dieser Gesten zählt damit als unerwartet, selbst wenn sie innerhalb von 500 Millisekunden auftritt (Quelle: Google web.dev).

Daraus folgt ein blinder Fleck: Eine Seite kann im Lighthouse-Labor einen makellosen CLS-Wert zeigen und trotzdem in den Felddaten schlechter abschneiden, weil reale Nutzer scrollen und dabei nachladende Bilder, Anzeigen oder Embeds Sprünge auslösen (Quelle: DebugBear). Felddaten liegen typischerweise höher als Laborwerte, weil sie genau diese Besuchsphasen abdecken. Der Visual Stability Index macht diesen Unterschied zum Maßstab - und damit wird der bisher tolerierte Bereich nach dem Laden zum bewertungsrelevanten Kern.

Die gute Nachricht: Wer bereits sauber an CLS gearbeitet hat, startet nicht bei null. Die Prinzipien - Platz reservieren, Bewegungen über die Compositor-Ebene laufen lassen, späte Injektionen vermeiden - bleiben dieselben. Sie müssen nur konsequent auf den Bereich nach dem Laden ausgedehnt werden. Eine begleitende Performance-Analyse mit Feld- und Labordaten zeigt, welche Templates beim Scrollen und Interagieren noch springen.

Lazy-Loading gehört zu den meistempfohlenen Performance-Techniken, weil es das initiale Ladegewicht senkt. In der Praxis wird es jedoch oft falsch eingesetzt und erzeugt dann genau die Sprünge, die VSI erfasst: Inhalte erscheinen erst beim Heranscrollen, ohne dass Platz für Bilder oder Embeds reserviert wurde, und schieben den darunterliegenden Inhalt nach unten (Quelle: DebugBear). Das Ergebnis ist eine ruckelnde Erfahrung während des Scrollens - im klassischen Labor-CLS unsichtbar, im Visual Stability Index voll wirksam.

Der gemeinsame Nenner ist derselbe wie beim Initial-CLS, nur an einer neuen Stelle: Platz reservieren, bevor Inhalt eintrifft. Der Unterschied liegt im Prüfverfahren. Ein statischer Labortest, der die Seite nur einmal lädt, deckt diese Sprünge nicht auf - es braucht ein Scroll-Profil, das die Seite wie ein echter Nutzer durchläuft. Wie sich kritische Ressourcen früh und unkritische spät ohne Stabilitätsverlust laden lassen, vertieft unser Beitrag zu fetchpriority und Priority Hints für LCP.

Der zweite große Bereich, den VSI gegenüber der klassischen CLS-Praxis aufwertet, ist die Interaktion. Hier liegt die Feinheit in der Absichtserkennung. Öffnet ein Nutzer ein Akkordeon und der Folgeinhalt rückt nach, ist das eine angeforderte Bewegung und in der Regel unproblematisch. Löst derselbe Klick jedoch eine ungeplante Verschiebung an einer ganz anderen Stelle aus - etwa weil ein Filter nicht nur die Liste, sondern auch das Seitenlayout umbaut -, kann das als unerwartet gewertet werden (Quelle: Core Web Vitals 2026 Branchenberichte).

Technisch bleibt die Leitregel bestehen: Bewegungen über transform: translate() und opacity umsetzen, weil diese Eigenschaften auf der Compositor-Ebene laufen und keinen Reflow auslösen. Änderungen an width, height, top oder margin zwingen den Browser zu einem erneuten Layout-Durchlauf und verschieben umliegende Elemente. Da VSI Interaktionsphasen mitbewertet, wird diese bislang vor allem für die Wahrnehmung wichtige Regel nun auch für die Stabilitätsmetrik relevant. Wie rechenintensive Reaktionen zusätzlich die Interaktivität belasten, betrachten wir im Kontext der Core Web Vitals 2026.

Weil VSI den ganzen Besuch bewertet, reicht ein einmaliger Labortest nicht aus. Entscheidend ist ein Messansatz, der die Seite wie ein echter Nutzer durchläuft: laden, scrollen, interagieren - und dabei jeden Sprung protokollieren. Felddaten aus dem Chrome User Experience Report bilden die reale Verteilung ab und aktualisieren sich über ein rollierendes 28-Tage-Fenster (Quelle: DebugBear), Maßnahmen werden also erst nach einigen Wochen vollständig sichtbar. Maßgeblich für die Bewertung bleibt das 75. Perzentil echter Nutzer (Quelle: Google web.dev) - ein im Labor sauberer Wert sagt wenig aus, wenn ein Viertel der Nutzer stärkere Sprünge erlebt.

Wer Felddaten ernst nimmt, kombiniert sie mit dem Wissen aus Real-User-Monitoring und den Verteilungen aus CrUX. Den Unterschied zwischen beiden Datenquellen und die Frage, wie sich daraus belastbare Performance-Budgets ableiten lassen, vertieft unser Beitrag zu RUM versus CrUX und Performance-Budgets.

In einem Shopware-Storefront auf Open-Source-Basis verlagern sich die kritischen Stellen mit VSI nach unten und in die Interaktion. Produktbild-Komponenten brauchen weiterhin width und height aus den Mediendaten, doch zusätzlich rücken Galerien, Cross-Selling-Sliders und Bewertungsblöcke in den Fokus, die per AJAX beim Scrollen nachgeladen werden. Sie gehören in reservierte Bereiche mit Skeleton-Platzhalter in der erwarteten Höhe. Filter auf Kategorieseiten sollten nur die Ergebnisliste austauschen, nicht das umgebende Layout, und die Liste behält ihre Mindesthöhe während des Ladens.

Der Vorteil dieses template-zentrierten Vorgehens bleibt unverändert: Wird eine Komponente einmal sauber gebaut, bleibt sie über alle Produkte, Kategorien und Landingpages stabil - jetzt eben auch während des Scrollens und der Interaktion. Diese Arbeit gehört in den Kontext einer umfassenden Shopware-Performance-Betreuung, die Stabilität, Ladezeit und Interaktivität gemeinsam betrachtet, statt isolierte Einzelfixes nachzuziehen.

Der wirtschaftliche Hebel liegt im Timing. Solange VSI als aufkommendes Signal Daten sammelt, hat eine Website Zeit, über das 28-Tage-Feldfenster saubere Werte aufzubauen, bevor der Faktor scharf geschaltet wird. Wer wartet, bis VSI offiziell rankingrelevant ist, startet erst dann mit der Datensammlung - und konkurriert dann mit Mitbewerbern, die ihre Felddaten bereits stabilisiert haben. Dass Layout-Stabilität auf das Geschäftsergebnis wirkt, ist gut belegt: Aktuell erreichen nur rund 47 Prozent (Core Web Vitals 2026 Branchenberichte) der Websites gute Werte über alle drei Core Web Vitals - ein klarer Differenzierungsraum nach oben.

Praktisch heisst das: Die bewährte CLS-Disziplin konsequent über den ganzen Besuch ausdehnen, mit einem Scroll- und Interaktionsprofil messen und die Ergebnisse gegen das 75. Perzentil echter Nutzer prüfen. Wer diese Schritte als Teil einer kontinuierlichen Frontend-Optimierung verankert, behandelt visuelle Stabilität nicht als kosmetisches Detail, sondern als planbaren Hebel auf Sichtbarkeit und Umsatz - lange bevor der Wettbewerb nachzieht.