What Is CLS (Cumulative Layout Shift)?

CLS (Cumulative Layout Shift) is the Core Web Vital that measures visual stability: how much a page's content unexpectedly moves while it loads. It is a unitless score, and Google considers 0.1 or less a good result.

CLS captures the frustration of reaching to tap a button or link, only to have it jump somewhere else at the last moment because an image, ad, or font finished loading and pushed everything down. It is one of the three Core Web Vitals Google uses as a user-experience signal, sitting alongside LCP (Largest Contentful Paint) for loading and INP (Interaction to Next Paint) for responsiveness. Where those two are measured in seconds and milliseconds, CLS is a unitless score, so lower is better and 0 means nothing shifted.

How CLS is scored

Each unexpected shift is scored as the impact fraction (the share of the viewport the moving content occupies) multiplied by the distance fraction (how far it travels relative to the viewport). CLS sums the largest cluster of these shifts during the page's lifetime. The thresholds are:

  • Good: 0.1 or less
  • Needs improvement: above 0.1 up to 0.25
  • Poor: above 0.25

As a worked example, a cookie banner that takes up 30% of the screen (impact 0.3) and pushes the content down by 25% of the viewport height (distance 0.25) produces a shift of 0.3 x 0.25 = 0.075. A second comparable shift would push the page past the 0.1 good threshold. Like the other vitals, CLS is judged at the 75th percentile of real visits, so the target is for at least 75% of page loads to score 0.1 or less, not just the average. The full pass requires LCP at 2.5 seconds or less, INP at 200 ms or less, and CLS at 0.1 or less, all at that 75th percentile.

Common causes and fixes

Most layout shift comes from elements that load without space reserved for them: images and video without width and height attributes, ads and embeds injected after render, web fonts that swap and resize text, and content inserted above what the visitor is already reading. The fixes are mostly about reserving space up front, for example setting explicit dimensions or an aspect-ratio box so the browser holds the slot before the asset arrives. A shift only counts against CLS when it is unexpected, so movement that follows a user action, such as expanding an accordion, is excluded.

Because CLS reflects what real people experience across different devices and connections, it is a field metric collected through real user monitoring rather than a single lab test. Lab tools estimate it, but synthetic checks cannot reproduce every visitor's layout shift, which is the same gap explained in synthetic monitoring vs real user monitoring. Pulsetic pairs that field data with uptime and API monitoring so availability and visual stability are tracked together.

See also: Synthetic vs real user monitoring

Frequently asked questions

  • What is a good CLS score?

    Google considers a CLS of 0.1 or less good, between 0.1 and 0.25 in need of improvement, and above 0.25 poor. The score is assessed at the 75th percentile of real page loads, so the goal is for at least three-quarters of visits to come in at 0.1 or less.

  • What causes a high CLS score?

    The usual culprits are images, ads, iframes, or embeds that load without space reserved for them, web fonts that swap and resize text, and content injected above what the visitor is already viewing. Each of these pushes existing elements out of the way, which registers as an unexpected layout shift.

  • How do I reduce Cumulative Layout Shift?

    Reserve space for anything that loads after render: set explicit width and height (or an aspect-ratio box) on images and video, allocate slots for ads and embeds, and preload fonts to limit text reflow. Avoid inserting content above existing content unless it is a response to a user action, which CLS does not count.

  • Is CLS measured in the lab or in the field?

    Both, but the version that affects Search is field data. Lab tools like Lighthouse estimate CLS from a single test load, while the real-world score that counts toward Core Web Vitals comes from real user monitoring across actual visitor sessions on varied devices and networks.