Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) measures unexpected movement of visible page content during a page's lifecycle. It is a Core Web Vital used to assess visual stability and is primarily improved by reserving space for content that loads or changes dimensions later.

A layout shift occurs when an element that was already rendered changes its position between rendered frames without the user causing the change. For example, an image loads without reserved dimensions and pushes a paragraph downward. User-initiated changes such as opening a menu after a click are generally not treated as unexpected layout shifts.

CLS combines the size of affected visible content with how far that content moves. A shift's score is based on an `impact fraction` multiplied by a `distance fraction`. The overall CLS uses layout-shift entries grouped into session windows rather than simply adding every shift throughout the entire page lifetime.

Common causes include images or videos without explicit dimensions, dynamically inserted content, late-loading fonts that alter text layout, and advertisements or embeds that change size after initial rendering. CSS animations and transitions should also be designed carefully so they do not trigger problematic layout movement.

A frontend engineer can reduce CLS by reserving dimensions with `width` and `height` or `aspect-ratio`, allocating space for dynamic content, avoiding inserting content above existing content, and handling fonts so that fallback-to-final-font changes cause minimal reflow. Browser performance tools and the `layout-shift` Performance API entry type can help identify which elements are moving.

Key points

• CLS measures unexpected visual movement, not general page loading speed.
• A layout shift score depends on affected area and movement distance.
• Reserve space for images, videos, ads, embeds, and dynamic content.
• User-triggered layout changes are treated differently from unexpected shifts.
• Use browser performance tooling to identify the elements responsible for shifts.

Interview questions

What is Cumulative Layout Shift?

CLS is a Core Web Vital that measures unexpected movement of visible page content during page use. A common example is an image appearing without reserved space and pushing text downward. The score considers both how much visible content is affected and how far it moves. Developers reduce CLS by making layout dimensions predictable before content arrives.

How is a layout shift score calculated?

A layout shift score is based on an impact fraction multiplied by a distance fraction. The impact fraction represents the portion of the viewport involved in the shift, while the distance fraction represents the largest movement distance relative to the viewport. CLS then aggregates shifts according to the metric's session-window rules rather than blindly summing every shift over the entire lifetime.

What are common causes of poor CLS, and how would you fix them?

Typical causes include images without dimensions, dynamically inserted content, advertisements that resize, and font changes that alter text metrics. I would reserve space for media with dimensions or `aspect-ratio`, allocate predictable regions for dynamic content, and make ad or embed containers stable. For fonts, I would evaluate loading and fallback behavior to reduce visible reflow. I would then use browser performance tools to identify the actual shifting elements rather than guessing.

Does every change to the page contribute to CLS?

No. CLS is concerned with unexpected movement of rendered content. Changes directly caused by user interaction, such as opening an interface element after a click, are treated differently from unsolicited shifts. The distinction matters because intentional interaction-driven changes should not be treated the same way as content unexpectedly jumping while the page loads.

How would you investigate a CLS problem in a real application?

I would first reproduce the problem under realistic loading conditions and inspect layout-shift entries in browser performance tooling. I would identify the DOM elements associated with the largest shifts and determine whether the cause is media sizing, injected content, fonts, ads, or another asynchronous update. I would then reserve the required space or change the rendering strategy and verify the result with field and lab measurements. Finally, I would monitor the metric over representative users because production behavior can differ from a local test.