CLS: causes and fixes

CLS measures how much the layout moves when nobody expects it: under 0.1 is good. The causes are images without dimensions, fonts that change metrics, banners inserted above the content and components that start at zero height.

How the score is built

Each shift is worth the impact fraction times the distance fraction: how much space the unstable element takes and how far it moves. Shifts within 500 ms of an input do not count, and the score adds up only the worst 5-second window.

The four causes that matter

Attributing the shift

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.log(entry.value.toFixed(4), entry.sources?.map((s) => s.node));
  }
}).observe({ type: "layout-shift", buffered: true });

In DevTools the Performance panel shows the same events as Layout Shift, with the rectangle of the element that moves. When sources is empty the shift comes from a node removed from the DOM: start from the components rendered above the fold.

Three fixes you can see in p75

• Give every image a width and height, or an aspect-ratio: the browser reserves the space before the file arrives.
• Reserve the height of banners and consent blocks in the markup, not with an animation on open.
• Give skeletons and lazy lists a minimum height: a container at zero pixels opens when the data lands and pushes everything below it.

The limitation you have to name

CLS does not say whether a shift annoys the reader: a banner that moves 3 px in the same font scores almost nothing, a heading that jumps 200 px ruins the read. Our p75 of 0.012 over 209 readings describes this site, not yours, and a local registry is not the field.

Where to continue

In the catalogue: card components, image auto slider and empty state. The guides: images without dimensions and what Core Web Vitals are; the sibling article on font-display and the comparison of copy-paste and headless.