Cumulative Layout Shift (CLS)
A Core Web Vitals metric measuring how much page content unexpectedly shifts during loading.
The Definition
Cumulative Layout Shift (CLS) measures the total amount of unexpected layout movement that occurs during the entire lifespan of a page. Layout shifts happen when visible elements change position without user interaction — typically caused by images without dimensions, dynamically injected content, or web fonts causing text reflow. Google considers CLS good below 0.1.
Why It Matters
High CLS frustrates users — buttons move just as they try to click, text jumps while reading, and ads push content down the page. It is a Core Web Vitals metric and Google ranking factor. Sites with good CLS provide noticeably better user experiences.
Best Practices
Always specify explicit width and height attributes on images and video elements so the browser reserves space before loading
Reserve space for dynamically injected content like ads, embeds, and iframes using CSS aspect-ratio or min-height
Use font-display: swap or font-display: optional to prevent layout shifts from web font loading
Avoid inserting content above existing content after page load — new content should appear below or in reserved spaces
Use CSS contain: layout on elements that should not affect surrounding layout during loading
Test CLS with real user monitoring, not just lab tools — field CLS includes shifts that happen throughout the page lifecycle
Mistakes to Avoid
- 1
Injecting cookie consent banners at the top of the page that push all content down, causing a large layout shift
- 2
Loading ads without reserved space, causing content to jump when the ad slot fills
- 3
Using images without width/height attributes in a responsive layout, causing reflow when images load
- 4
Dynamically changing font sizes or loading custom fonts that cause visible text reflow
Audit Checks
How Digispot AI identifies and fixes related issues
Content jumps around as the page loads — buttons or text shift under the reader (a high Cumulative Layout Shift, or CLS, over 0.1).
Impact: Layout jumps frustrate visitors with mis-clicks and lower your Google ranking.
Set explicit width and height on every image and video. • Reserve space for ads, embeds, and banners before they load. • Avoid inserting content above what the reader is already viewing.
The page is slow to respond when a visitor interacts with it — taps, clicks and key presses lag (Interaction to Next Paint, or INP, over 200ms).
Impact: INP is a Core Web Vital and Google ranking signal; a laggy interaction makes the page feel broken and drives visitors away.
Break up long JavaScript tasks so the main thread can respond sooner. • Defer or remove scripts that aren't needed for the first interaction. • Move heavy computation off the main thread (web workers).
The HTML document alone is larger than 2MB — past Google's documented 2MB indexing limit. Images, CSS and JS are fetched separately and do NOT count toward this.
Impact: Google only indexes the first 2MB of HTML, so any content past that point in the document risks never being indexed.
Trim large inline scripts and JSON embedded in the HTML. • Paginate huge lists and move bulk data out of the initial HTML. • Enable server-side compression to shrink the document below 2MB.
The biggest thing on the page — usually the hero image or main heading — takes more than 2.5 seconds to appear (its Largest Contentful Paint, or LCP).
Impact: Google uses LCP as a ranking signal, and visitors often leave before a slow page finishes loading.
Compress the largest above-the-fold image and serve it as WebP or AVIF. • Preload that hero image and your main web font so they load first. • Remove or defer render-blocking scripts and CSS.
Some CSS or JavaScript must finish loading before the page can show anything.
Impact: Render-blocking resources delay the first paint, making the page feel slow.
Defer or async-load non-critical JavaScript. • Inline the critical CSS the first view needs. • Move the rest of the CSS to load later.
The HTML document is between 1.5MB and 2MB — getting close to Google's 2MB HTML indexing cap (subresources like images/CSS/JS don't count).
Impact: If the HTML grows past 2MB, content beyond that point stops being indexed.
Trim inline scripts/JSON and oversized markup in the document. • Paginate long lists rendered directly into the HTML. • Keep the HTML document well below 1.5MB.