Visual Stability Index 2026: The Next CLS Step

CLS was designed as a metric for the unexpected movement of visible elements. In field measurement, CLS already captures the entire page lifetime, but in practice -- and especially in lab tests -- the load phase dominates the picture. A headless browser loads the page once, without scrolling, without a mouse, without interaction, and therefore sees only the shifts of the initial phase (Source: DebugBear). This is exactly where the Visual Stability Index comes in: it evaluates visual stability across the complete visit and thereby captures shifts that CLS systematically underestimates in common optimization practice -- such as during scrolling or with late-loading content (Source: Core Web Vitals 2026 industry reports).

The decisive conceptual difference is intent awareness. VSI is considered intent-aware: movements that users trigger themselves and expect -- an expanding accordion, a filter that re-sorts a list, a carousel that advances on click -- are generally not scored negatively. What gets penalised are unexpected shifts, such as late banners, delayed ads, snapping sticky elements or dynamically injected content (Source: Core Web Vitals 2026 industry reports). This moves optimization away from the pure load phase toward the question: does the layout stay calm even while the user is using it?

Important for context: VSI is currently considered an emerging signal, not a primary ranking factor like LCP, INP or CLS. Industry reports assume that Google is already collecting data through the Chrome User Experience Report and that VSI, following the pattern of earlier Core Web Vitals rollouts, could become a primary factor within 12 to 18 months (Source: Core Web Vitals 2026 industry reports). This lead time is the real lever -- those who stabilise now gather clean field data before the factor goes live.

Previous CLS practice concentrates on the visible area during initial render: images above the fold get dimensions, the hero area is stabilised, web fonts are preloaded. That is correct and remains the basis. But as soon as the user scrolls, an area begins that lab tests rarely enter. Continuous interactions such as scrolling, dragging or zooming explicitly do not count as recent input in the sense of the recent-input window -- every shift during these gestures therefore counts as unexpected, even if it occurs within 500 milliseconds (Source: Google web.dev).

This creates a blind spot: a page can show a clean CLS value in the Lighthouse lab and still score worse in field data because real users scroll and trigger shifts from late-loading images, ads or embeds (Source: DebugBear). Field data is typically higher than lab values because it covers exactly these visit phases. The Visual Stability Index makes this difference the yardstick -- and so the previously tolerated area after loading becomes the assessment-relevant core.

The good news: anyone who has already worked cleanly on CLS does not start from zero. The principles -- reserve space, run movements on the compositor layer, avoid late injections -- stay the same. They only need to be extended consistently to the area after loading. An accompanying performance analysis with field and lab data shows which templates still jump during scrolling and interaction.

Lazy loading is one of the most recommended performance techniques because it reduces the initial load weight. In practice, however, it is often misused and then creates exactly the jumps VSI captures: content appears only on scroll, without space reserved for images or embeds, and pushes the content below it downward (Source: DebugBear). The result is a janky experience during scrolling -- invisible in classic lab CLS, fully effective in the Visual Stability Index.

The common denominator is the same as for initial CLS, just in a new place: reserve space before content arrives. The difference lies in the test procedure. A static lab test that loads the page only once does not surface these jumps -- it takes a scroll profile that runs through the page like a real user. How to load critical resources early and non-critical ones late without losing stability is explored in our article on fetchpriority and priority hints for LCP.

The second major area that VSI upgrades compared to classic CLS practice is interaction. The subtlety here lies in intent awareness. If a user opens an accordion and the following content moves down, that is a requested movement and usually unproblematic. But if the same click triggers an unplanned shift somewhere else entirely -- for example because a filter rebuilds not only the list but also the page layout -- it can be scored as unexpected (Source: Core Web Vitals 2026 industry reports).

Technically, the guiding rule remains: implement movements via transform: translate() and opacity, because these properties run on the compositor layer and trigger no reflow. Changes to width, height, top or margin force the browser into another layout pass and shift surrounding elements. Since VSI evaluates interaction phases too, this rule -- previously mainly important for perception -- now becomes relevant for the stability metric as well. How compute-heavy responses additionally burden interactivity is examined in the context of Core Web Vitals 2026.

Because VSI evaluates the whole visit, a one-off lab test is not enough. What matters is a measurement approach that runs through the page like a real user: load, scroll, interact -- and log every jump along the way. Field data from the Chrome User Experience Report reflects the real distribution and updates over a rolling 28-day window (Source: DebugBear), so measures become fully visible only after a few weeks. The decisive benchmark remains the 75th percentile of real users (Source: Google web.dev) -- a value that looks clean in the lab says little if a quarter of users experience stronger jumps.

Anyone who takes field data seriously combines it with insights from real-user monitoring and the distributions from CrUX. The difference between the two data sources and how to derive robust performance budgets from them is explored in our article on RUM versus CrUX and performance budgets.

In a Shopware storefront on an open-source basis, the critical spots move downward and into interaction with VSI. Product image components still need width and height from the media data, but in addition galleries, cross-selling sliders and review blocks that load via AJAX on scroll come into focus. They belong in reserved areas with skeleton placeholders at the expected height. Filters on category pages should swap only the result list, not the surrounding layout, and the list keeps its minimum height while loading.

The advantage of this template-centric approach remains unchanged: once a component is built cleanly, it stays stable across all products, categories and landing pages -- now also during scrolling and interaction. This work belongs in the context of a comprehensive Shopware performance service that considers stability, loading time and interactivity together instead of pulling in isolated single fixes.

The economic lever lies in timing. As long as VSI is collecting data as an emerging signal, a website has time to build clean values across the 28-day field window before the factor goes live. Those who wait until VSI is officially ranking-relevant only start collecting data then -- and then compete with rivals who have already stabilised their field data. That layout stability affects business results is well documented: currently only around 47 percent (Core Web Vitals 2026 industry reports) of websites reach good values across all three Core Web Vitals -- a clear headroom for differentiation.

In practice this means: extend the proven CLS discipline consistently across the whole visit, measure with a scroll and interaction profile and check the results against the 75th percentile of real users. Anyone who anchors these steps as part of a continuous frontend optimization treats visual stability not as a cosmetic detail but as a plannable lever on visibility and revenue -- long before the competition catches up.