Cumulative Layout Shift (CLS) is a Core Web Vital metric that quantifies visual stability by measuring unexpected movement of page elements during load and interaction. It's scored from 0 upward, with values under 0.1 considered good, and directly affects both user experience and Google rankings.
CLS isn't a simple count of things that move. It's a dimensionless score calculated by identifying layout shift events—moments when a visible element changes its start position between two rendered frames without user interaction triggering it. For each shift, Google's algorithm multiplies two fractions. The impact fraction measures what portion of the viewport experienced movement. If half the visible screen area saw elements relocate, that's 0.5. The distance fraction captures how far elements moved relative to viewport height or width, whichever is larger. A banner that drops 25 percent of the viewport height yields 0.25. Multiply them (0.5 × 0.25 = 0.125 for that one shift), then sum all individual shift scores that occur within a session window. Google groups shifts into windows capped at five seconds with one-second gaps, then reports the worst window's total. This windowing prevents artificially high scores on long sessions while still penalizing clusters of instability.
Before CLS became a Core Web Vital in 2020, Google had no standardized way to measure visual stability at scale. Layout shifts cause real usability failures—users click a button just as an ad loads above it, sending the tap to the wrong target, or begin reading a paragraph that suddenly jumps when a font swaps in. These interruptions correlate with frustration and exits, but they're invisible in traditional speed metrics like First Contentful Paint or Time to Interactive. CLS fills that gap by quantifying layout instability the way users experience it. It replaced earlier experimental metrics like Layout Instability API scores that didn't account for session length. The current version uses field data collected from Chrome browsers in the real world, making it harder to game with lab-only optimization. For SEO, CLS sits alongside Largest Contentful Paint and First Input Delay (now Interaction to Next Paint) as the three Core Web Vitals that Google confirmed as ranking signals in the page experience update.
Images and embeds without explicit width and height attributes top the list. When a browser parses an img tag with no dimensions, it allocates zero space initially, then reflows the page when the file downloads and its true size is known. The same applies to iframes, video players, and any embedded content. Web fonts cause shifts if you rely on invisible fallback text (FOIT) or unstyled fallback (FOUT) without size-adjust or font-display tuning. A heading set in a custom font can collapse or expand when the web font renders. Dynamically injected content is another frequent culprit—think newsletter signup modals, cookie banners, or promotional ribbons inserted above existing DOM nodes. Third-party ad tags and social widgets are especially problematic because you don't control their dimensions or load timing. Finally, animations and transitions that change element geometry without transform properties trigger reflows. A dropdown menu that shifts the footer downward instead of overlaying scores as a layout shift.
Lighthouse in Chrome DevTools gives you a CLS score, but it reflects a single simulated load on your machine—not what real visitors experience. Lab scores are useful for debugging because you can throttle network, adjust cache state, and inspect which elements shifted in the filmstrip view. They're terrible for judging actual performance because CLS varies wildly based on device speed, connection quality, and user behavior. Field data comes from the Chrome User Experience Report, aggregated anonymously from opted-in Chrome users over a rolling twenty-eight-day window. You see this in PageSpeed Insights under the field data section and in Search Console's Core Web Vitals report, which shows URL-level pass/fail based on the seventy-fifth percentile. A page passes if seventy-five percent of real visitors saw CLS below 0.1. Relying solely on Lighthouse can mislead you into thinking a page is stable when field users are experiencing shifts you didn't reproduce locally. Always cross-reference both sources.
Set explicit width and height on every image and iframe in your HTML, even if CSS resizes them. Modern browsers use aspect-ratio internally to reserve space before the resource loads. For responsive images, the browser calculates the ratio from your attributes and applies it regardless of CSS scaling. Use font-display: swap cautiously—it avoids invisible text but can cause layout shift if the fallback and web font have different metrics. Instead, adjust your fallback font's size, weight, and letter-spacing to approximate the web font using size-adjust, ascent-override, and descent-override in your @font-face rule. Reserve space for ads and embeds by wrapping them in containers with min-height set to the smallest expected size, or use skeleton placeholders. Avoid inserting content above existing DOM nodes after page load—if you must show a banner, overlay it or push content from a reserved space. Prefer CSS transforms and opacity for animations instead of changing top, left, width, or height. Transforms don't trigger layout recalculations. Test each change in both Lighthouse and Search Console field data, because the fixes that matter are the ones that improve real-user scores.
Many assume CLS only measures initial page load, but it captures shifts throughout the session window—scrolling, clicking, and background DOM updates all count if they trigger unexpected movement. User-initiated shifts, like expanding an accordion or clicking to load more content, are excluded because Google detects the input event within five hundred milliseconds of the shift. Another trap: focusing only on the homepage. CLS often spikes on article pages with mid-content ads or product pages with image galleries. Search Console groups URLs by similarity, so one bad template can fail an entire section. Some developers think fixing CLS means eliminating all movement, leading them to block legitimate interactions or over-engineer skeleton states that hurt perceived performance. The goal is predictable movement—reserve space, animate with transforms, signal what's about to happen. Also, aggressive lazy-loading can worsen CLS if images pop in as users scroll before space is reserved. You need dimensions on lazy-loaded images just as much as eager-loaded ones.
Google defines a good CLS score as 0.1 or lower, measured at the seventy-fifth percentile of real user visits. Scores between 0.1 and 0.25 need improvement, and anything above 0.25 is poor. These thresholds apply to field data from actual visitors, not lab-simulated loads. Your page passes Core Web Vitals if at least seventy-five percent of users experience CLS below 0.1 over the past twenty-eight days.
Yes, CLS is one of three Core Web Vitals Google confirmed as ranking signals in the page experience update. Pages that fail CLS in field data may rank lower than competitors with stable layouts, all else being equal. The effect is typically modest—content relevance and authority still dominate—but for queries where multiple pages are closely matched, better CLS can tip the balance. It also reduces pogo-sticking, which indirectly helps rankings.
Lighthouse runs a single simulated load in controlled lab conditions, while Search Console reports field data from real Chrome users over twenty-eight days. Field CLS includes diverse devices, network speeds, and user interactions that lab tests can't replicate. A page might score zero in Lighthouse but fail in the field if certain ads or third-party scripts cause shifts only under specific conditions. Always prioritize fixing issues visible in Search Console field data.
Absolutely, and this is a common mistake. If you lazy-load an image without setting width and height attributes, the browser reserves no space until the image enters the viewport and loads, causing everything below it to jump. The solution is to specify dimensions on every img tag regardless of loading strategy. Modern browsers calculate the aspect ratio and reserve space even when loading is deferred, preventing the shift.
It depends on how you animate. Changing properties like top, left, width, height, or margin triggers layout recalculation and counts as a shift. Using CSS transform and opacity does not, because transforms operate on the GPU without reflowing the page. If you animate a modal sliding in, use transform: translateY instead of changing the top value. This keeps your CLS score clean while still delivering smooth motion.
In Chrome DevTools, open the Performance panel and record a page load while checking the Experience row. Layout shifts appear as red bars; click one to see which elements moved in the Summary pane. Lighthouse also flags specific shifting elements in its diagnostics. For field data, you can't see individual elements, but you can instrument your own RUM solution using the Layout Instability API to log shift sources in production and aggregate them for analysis.