In one paragraph
Cumulative Layout Shift too high means content moved unexpectedly during the measured page load. Images without reserved dimensions, late embeds, inserted banners, and changing font metrics are common causes. Identify the shifting elements in a browser trace and reserve appropriate space. Interpret WebAuditOS's documented load-time sum separately from standard session-window CLS and real-user measurements before comparing scores.
Why it matters
Unexpected movement can make readers lose their place or tap a control that moved under their finger. CLS measures visual instability using the area and distance involved in eligible shifts, not simply the number of animated elements.
Standard CLS uses the largest session window: a burst with less than one second between shifts and at most five seconds in total. Shifts sufficiently close to qualifying recent input can be excluded; scrolling does not broadly excuse every late layout change. Standard good and poor boundaries are 0.1 and 0.25 respectively, with field assessment based on the 75th percentile.
A load-only laboratory run does not capture every shift caused by later scrolling, widget updates, or long interactions. A stable-looking warm desktop visit also does not establish stability on a cold mobile load.
How WebAuditOS evaluates this finding
The supplied implementation loads sampled pages at 390×844 with the documented mobile throttling and sums eligible layout-shift entries until network idle or its fifteen-second wait limit. Up to 0.1 passes; over 0.1 through 0.25 warns; over 0.25 fails. Unmeasured or unrendered pages are not graded.
Its sum across the load differs from standard session-window CLS. Separate bursts can make it higher, while later real-user shifts can make field experience worse than the sampled load. Treat this as the documented scanner indicator, not a directly interchangeable CrUX or Lighthouse value.
How to fix it
- Reproduce on a phone-sized viewport with controlled network and CPU settings. Record a reload in the Performance panel and inspect layout-shift events. Identify both the moved elements and the content change that displaced them; those are not always the same element.
- Reserve media space before bytes arrive. Supply correct image width and height or an appropriate aspect-ratio. For responsive images, preserve the ratio with CSS rather than forcing inconsistent dimensions:
img { max-width: 100%; height: auto; }Use markup dimensions corresponding to the asset's intended ratio, not arbitrary values added only to satisfy a tool.
- Give embeds and ad slots predictable containers. Choose sizes responsive to the real layout. Decide how unavailable content should appear without collapsing a visible block unexpectedly.
- Avoid inserting new content above what a visitor is already reading. Render an appropriate placeholder from the start, place updates where they do not displace existing content, or use a carefully tested overlay that remains accessible and does not obscure necessary controls.
- Review web-font changes. Match fallback metrics using suitable font descriptors and test line wrapping at relevant widths. font-display: swap improves text visibility but can still move text if metrics differ.
- Prefer suitable transform-based motion to layout-changing animation where that matches the design. Do not hide a required state change from assistive technology merely to reduce a visual metric.
- Repeat tests through cookie-consent states, ads, late-loaded widgets, and scrolling. Keep consent controls usable and accurate; their legal purpose should not be sacrificed to make a score green.
- Rescan, compare standard browser CLS separately, and inspect field data when available. Confirm that changes reduce the actual shifts rather than simply moving them past the lab observation window.
What the fix can break
Reserved space can become an empty gap when a provider returns no content. Plan a reasonable unavailable state rather than collapsing it at an arbitrary moment in view.
Incorrect media dimensions can distort content. Large font changes can move buttons or navigation at narrow widths even when desktop looks stable.
Overlaying every banner can obscure content or trap interaction. Judge usability and accessibility along with the metric. A lower sum is not a complete approval of the new interface.
Questions
Why is the scan higher than Lighthouse?
One documented reason is summing all observed shifts instead of selecting the largest session window. Also compare device, timing, and loaded content.
Can a passing load still have bad field CLS?
Yes. Field measurements can include eligible shifts later in the visit that the laboratory load never observes.
Are width and height safe on responsive images?
They can reserve an aspect ratio while CSS scales the image. Use correct values and preserve proportional sizing.
What should I review next?
Review LCP, blocking time, and the Core Web Vitals guide.