Core Web Vitals: CLS indicator - causes and optimisation methods
The Core Web Vitals CLS indicator has become a benchmark for assessing the visual stability of an interface. It measures the unexpected shifts that disrupt reading and use of content during loading or navigation. Google includes it in the web vitals to better connect technical quality and real-world experience.
A good CLS indicator is not just a number in a report. It reflects a page's ability to remain stable, without abruptly moving blocks, links or buttons. For an editorial, e-commerce or institutional project, this stability directly influences perceived quality and conversion.
The following sections explain how this metric works, the thresholds to aim for, the most common causes and the most effective optimisation methods. You will also see which tools to use to diagnose the problem and how to read field data with Google.
What is CLS in the Core Web Vitals?
CLS, which stands for cumulative layout shift, measures the visual stability of an interface while it is being displayed. The higher the score, the more elements move unpredictably on the screen. Google uses it as a quality metric to identify unstable visual experiences.
In concrete terms, a user sees a button, starts to aim for an action, then a block above it loads and pushes everything down. This kind of movement creates an unpleasant surprise, even if the final content is correct. This is precisely what this indicator seeks to quantify.
Why this metric matters so much
Visual stability is essential, as it determines readability and trust. An interface that moves constantly gives the impression of being poorly built, even if its response time is good. Google therefore considers this metric a useful signal for assessing the overall quality of a site.
In the core web vitals, each indicator covers a different aspect of the display. CLS focuses on movement, while other metrics track rendering speed or responsiveness. Together they give a more complete picture of perceived quality.
What a shift really measures
A movement is not penalised simply because it exists. It has to be unexpected, visible and likely to hinder reading or action. In this way, Google seeks to distinguish normal movements from problematic shifts.
- A visible movement of a text block.
- A shift of a button or a link during loading.
- The late insertion of an element that pushes the rest of the content down.
What CLS score should you aim for?
The threshold recommended by Google is a score less than or equal to 0.1. Between 0.1 and 0.25, the situation is considered one to watch. Above 0.25, visual stability becomes clearly insufficient.
To track this metric correctly, you need to look at the distribution of real visits and not a single run in the lab. Google relies in particular on the 75th percentile, which lets you assess the experience of the majority of sessions rather than an isolated case.
How to interpret the thresholds
A good result means that most visitors do not experience a disruptive shift. An average result indicates that some sessions still encounter instabilities. A poor result often reflects a structural problem with the layout or the loading of resources.
- 0 to 0.1: good level.
- 0.1 to 0.25: improvement recommended.
- Above 0.25: high priority.
Why the percentile is important
The 75th percentile avoids overestimating or underestimating a result. A single very stable session is not enough to guarantee a good indicator, just as an isolated disrupted session should not skew everything. Google therefore favours a more representative view of traffic.
This approach helps track variations in behaviour depending on the device, the cache or the network quality. It is particularly useful for managing a site at scale, where real-world conditions vary a great deal.
How is the CLS score calculated?
The calculation relies on two components: the impact fraction and the distance fraction. The first corresponds to the visible area affected by the shift, the second to the amplitude of the movement relative to the viewport. Their product gives the weight of an event in the measurement.
Google does not treat all shifts in the same way. Successive changes are grouped within a session window, also called a burst, which avoids cumulating movements that are far apart in time. This logic helps reflect the sequences that are genuinely disruptive.
Impact fraction and distance fraction
The impact fraction represents the part of the screen that was affected. If a large text block shifts, the value climbs quickly. The distance fraction, meanwhile, measures the distance travelled by that element within the visible area.
The product of the two gives a more nuanced result than a simple count of events. This is what makes the metric relevant for assessing the real intensity of a visual shift.
The 5-second session window
Google groups closely spaced shifts within a maximum window of 5 seconds. If the movements are separated by more than 1 second, a new burst can begin. This prevents an old problem from continuing to artificially inflate the result.
This rule lets you identify the sequences where several elements move one after another. For diagnosis, this is a key point, as the issue often comes from a group of elements injected at the same moment.
Which layout shifts are taken into account?
Not all movements are considered problematic. Google excludes shifts triggered directly by a deliberate action, as they are expected. The aim is to target what surprises the user during reading or navigation.
The notion of layout shift therefore does not cover every change of position. It applies above all to unexpected shifts, deferred behaviours and blocks that resize without reserving space.
Expected shifts
A movement caused by a click, a tap or a deliberate opening is generally ignored if the system identifies the interaction as recent. Google uses a marker such as hadRecentInput to filter these cases. In practice, this avoids penalising an intended action.
The 500-millisecond rule after an action is important. If the shift occurs too late, it may no longer be considered legitimate. The behaviour must therefore stay close to the initial intent to be excluded from the calculation.
Unexpected shifts
Changes that occur without a clear gesture from the user are taken into account. This includes ad blocks, images without a reserved size, banners, late tooltips or modules injected after the fact. These are often the most costly cases in terms of perceived quality.
In practice, the browser cannot guess that a space is suddenly going to expand. When the layout is not anticipated, the rest of the content has to reorganise itself, which creates the shift measured by Google.
What are the main causes of a poor CLS?
The most common causes are linked to the absence of reserved space. An image without dimensions, an ad that inserts itself late or a font that changes the size of the text can be enough to strongly degrade the result. The problem is often more visible in production than in development.
Locally, the cache, already-loaded resources and test conditions sometimes mask the flaws. In a real environment, browsers have to cope with varied connections, third-party scripts and personalised content. Google then observes shifts that internal tests do not always reveal.
Media without dimensions
Images and videos without a reserved width or height trigger a recalculation of the layout when they arrive. The browser then has to push the following blocks down or move them sideways. This is a classic source of poor stability.
The case is even more visible in editorial areas rich in media. When a large visual appears after the text, reading is interrupted and the content jumps abruptly.
Ads, widgets and injected content
Ad slots that change size are among the most common causes. A social widget, a product recommendation or an information banner can also shift the layout if they are loaded too late. Google penalises above all the areas that insert themselves above content that is already visible.
Third-party components are often unpredictable, as their size depends on external scripts or asynchronous data. To optimise stability, you need to reserve a fixed space and avoid sudden insertions into the flow.
Web fonts and typographic rendering
A font loaded late can change the size of the characters and make the lines move. The FOUT phenomenon, or font substitution, is a common case. If the typographic metrics change, the length of paragraphs varies and the surrounding blocks reorganise themselves.
To reduce this risk, it is useful to use font-display: swap with care and to preload critical fonts. This kind of setting limits the differences between the fallback font and the final font.
Should you analyse CLS in the lab or in the field?
Both approaches are useful, but they do not answer the same question. Lab measurements are used to diagnose a problem in a controlled environment. Field data describes what real visitors experience under varied conditions.
Google recommends favouring real-world data for SEO management, as it better reflects the diversity of devices, browsers and network conditions. A good diagnosis therefore combines local inspection with observation of real usage.
Why the results can diverge
A lab test does not necessarily see the variations linked to the cache, personalised content or the bfcache. Some browsers restore the page differently when a user goes back. These behaviours change the final result.
In production, real journeys are more complex. One visitor may land on an area with promotions, another on a different variant, and Google then observes differences that do not appear in a single test.
Which data to favour
For a prioritisation decision, field data should come first. It lets you know whether the problem affects a large number of visits or only a rare scenario. Lab tests are then used to reproduce and fix the flaw.
This logic avoids fixing a theoretical detail while a genuine blocker persists for users. It also lets you measure the effect of a fix over time.
Which tools should you use to measure CLS?
Several tools let you observe this metric from different angles. Some are used for field tracking, others for technical diagnosis, and others again for one-off audits. The right choice depends on the moment at which you intervene.
Google offers several complementary sources for reading visual stability. It is often worth cross-referencing a real-world monitoring tool and a local analysis tool in order to understand the problem in its context.
The solutions to favour
- Search Console: useful for spotting the groups of affected URLs.
- PageSpeed Insights: handy for connecting field data and diagnostics.
- Lighthouse: effective in the lab for spotting causes.
- Chrome DevTools: useful for visualising shifts in the browser.
- CrUX: a source of real-world data aggregated by Google.
How to choose according to your goal
To monitor the overall trend, aggregated data is the most useful. To fix a specific flaw, a local diagnosis will be more relevant. PageSpeed Insight and Google Search Console are often complementary, as they help connect the observation to concrete URLs.
The field report shows what is really happening, while lab analysis helps you understand why. This combination gives a more reliable view of the situation.
Using the web-vitals tool in development
The web-vitals library makes it easy to instrument collection on the browser side. It provides a reliable basis for sending the signals to your analytics system. It is a good resource for tracking changes without waiting for an aggregated report.
In practice, it is best to report the data at the moment the tab moves into the background or just before it closes. This reduces the loss of information and improves the quality of the measurement.
How do you measure CLS in JavaScript?
Browser-side measurement relies on observing layout-shift entries via PerformanceObserver. At each event, you can record the value, group the sequences and calculate the relevant cumulative total. This approach lets you track the metric in real time.
Google recommends sending the results at the end of a session or when switching to the background. This moment is important, as it often corresponds to the last useful value before the user leaves the browser.
Observing shift events
The browser exposes signals that can be aggregated to obtain a reliable measurement. The idea is not just to count movements, but to keep the significant shifts within the appropriate time window. This avoids mistaken interpretations.
A well-thought-out implementation also lets you distinguish user-triggered events from the rest. You can then pass on actionable information for product or SEO management.
When to send the data
The right moment to send the information is the end of the useful journey. If the user switches tabs or leaves the page, the last values should be retrieved immediately. This limits losses caused by the script being interrupted.
In a browser environment, this logic improves the reliability of tracking on short or unstable sessions. It complements the reports provided by Google nicely.
How do you avoid CLS caused by images and videos?
The first rule is to reserve the space before the media loads. Adding width and height to media lets the browser calculate the required space from the start. This is the simplest way to avoid an unexpected shift.
When the dimensions are not known in advance, CSS techniques such as aspect-ratio can take over. They maintain a stable template while the visual arrives.
Reserve the right space from the start
A media element that arrives without a frame forces the browser to reorganise the structure. If the space is already reserved, the display becomes smoother and the rendering looks cleaner. This rule applies to images, videos and enriched thumbnails.
On rich interfaces, this simple adjustment can clearly improve overall stability. It also avoids domino effects on the blocks below.
Optimise media in a coherent way
Compressing an image is not enough to solve the problem. You also need to make sure that its visual integration is anticipated by the browser. Good optimisation combines reduced weight, known dimensions and reserved space.
For embedded videos, it is useful to provide a stable container even before playback. This limits the rearrangements at the moment the resource becomes available.
How do web fonts influence CLS?
Web fonts can change the rendering of the text when they replace a temporary system font. If the character metrics are not close, the lines reorganise themselves and the blocks move. The result then becomes less stable.
Google detects these effects as layout shifts, especially when they affect long paragraphs or navigation areas. You therefore need to anticipate the typographic behaviour from the design stage.
Reduce substitution effects
The font-display: swap setting lets you quickly display readable text while waiting for the final font. This improves the perception of speed, but you need to check that the switch does not create too strong a variation in width. The choice of fallback fonts matters a great deal.
Preloading critical fonts also helps reduce the delay. The less time the font takes to arrive, the lower the risk of a shift.
Stabilise the typography
A coherent typographic strategy limits surprises. It is advisable to choose secondary fonts close to the main font in height, weight and width. The aim is to keep a stable display even in the event of latency.
In a heavily editorial environment, this point can make a real difference. Continuous reading improves satisfaction and reduces visual interruptions.
How do you limit CLS caused by ads and third-party content?
Ads, pop-ups, banners and external widgets are frequent sources of instability. They often arrive after the rest of the content and can expand their area without warning. Google then considers this behaviour a penalising shift.
The good practice is to reserve a fixed slot even before the component loads. This anticipation saves the rest of the layout from having to reorganise itself in a hurry.
Reserve a dedicated space
A container of known size protects the overall structure. Even if the third-party module loads later, it will not need to push the other blocks. The rendering looks cleaner and more reliable.
This logic is particularly useful for ad slots, recommendation modules and promotional banners. It limits the visible effects above the main text.
Avoid abrupt insertions
Inserting a block in the middle of an already-displayed flow is a bad practice if the space was not planned for. It is better to place these elements in a reserved area or at the end of the content. The interface then stays more stable.
When a dynamic addition is essential, you should at the very least preserve the space before it arrives. It is a simple rule, but a very effective one for improving the result.
Which animations can you use without degrading CLS?
Animations are not forbidden, but they should avoid properties that force a layout recalculation. Transitions based on top, left, width or height risk moving other elements. This can degrade the indicator even if the visual effect seems smooth.
Google and development best practices recommend favouring transform: translate() and transform: scale(). These properties act more cleanly on the rendering without disrupting the whole structure.
The properties to favour
- transform: translate() to move a block.
- transform: scale() to visually enlarge or shrink.
- opacity to create a subtle transition.
The mistakes to avoid
Changing the height or width of a block to animate its opening is often risky. The surrounding environment then has to recalculate, which can cause cascade effects. A visually pleasing animation can therefore remain technically costly.
It is better to anticipate the required space and let the animation act inside that frame. This method lets you improve visual comfort without penalising stability.
What place does CLS hold among the Core Web Vitals?
In the core web vitals, CLS complements indicators linked to speed and responsiveness. LCP measures the display of the main element, while other metrics assess responsiveness. CLS focuses on visual stability, which makes it a complementary but essential indicator.
Google considers these signals together to appreciate the overall quality of an interface. A good result on one metric does not always make up for a major flaw on another, which is why it is worth tracking the whole set.
An indicator you should not isolate
A good CLS is not enough if the rest of the journey is slow or unresponsive. Conversely, a fast but unstable interface remains penalising for usage. The web vitals should therefore be read as a coherent whole.
This global reading helps prioritise fixes. It also makes it easier to explain the priorities to product, editorial and technical teams.
What is the impact of CLS on SEO and the user experience?
Google takes visual stability into account in its quality assessment. A good indicator contributes to a better perception of the result and to more comfortable navigation. With equivalent content, a stable interface can make the difference.
The effect is also indirect on visitor behaviour. When elements do not move unpredictably, reading stays smooth, clicks are more reliable and trust increases. This is an important point for both SEO and conversion.
Effects on satisfaction and conversion
An interface that jumps on loading can cause misclicks, frustration and sometimes an abandonment. Google observes this kind of signal indirectly through perceived quality. For a merchant or editorial site, stability then becomes a real performance lever.
By improving this metric, you reduce the risk of reading interruptions and strengthen credibility. The benefit is often visible on long journeys or interfaces rich in modules.
A sustainable optimisation approach
Improving this metric does not rest on a single fix, but on a series of best practices applied across the whole chain. Reserving space, loading resources cleanly, controlling third-party scripts and tracking real-world data all help keep a good level over time.
Google values stable environments, as they offer a better quality of use. This is why regular measurement, analysis of regressions and continuous optimisation remain indispensable.
Key takeaways on the Core Web Vitals CLS indicator
CLS measures visual stability and identifies the unexpected shifts that disrupt reading. To stay within the zone recommended by Google, you need to aim for a score below 0.1 and monitor field data as a priority. The most common causes concern images, fonts, third-party elements and dynamic insertions.
The best approach is to anticipate spaces, use the right tools and validate fixes in the browser as well as in Google's reports. By keeping this stability mindset, you can lastingly improve the perceived quality and the overall effectiveness of your web vitals.
