How to Fix CLS From Dynamic Ads, Cookie Banners and Embeds

How to Fix CLS From Dynamic Ads, Cookie Banners, and Embeds-  Complete Guide

Dynamic ads, cookie banners, chat widgets, and third-party embeds are the second most common cause of CLS failures after unsized images. They cause a layout shift by injecting content above existing page elements after the initial render. The fix is always the same principle: reserve the space before the content arrives. This guide covers every type of dynamic content injection and the exact fix for each one.

You have fixed your image dimensions. Your fonts are loading cleanly. But your CLS score is still failing.

The culprit is almost always dynamic content — something injecting itself into your page after it has already loaded and pushing everything else down in the process.

Ad networks that load a 250px banner into a zero-height container. Cookie consent bars that slide in above your header. Chat widgets that expand from nothing. YouTube embeds that resize their container when the iframe loads. All of them cause layout shift. All of them are fixable.

This article covers every type of dynamic content injection, why each one causes CLS, and the exact implementation to eliminate the shift on every platform.

If you are still working out which Core Web Vitals is failing or want to understand CLS from the beginning, start with what causes cumulative layout shift before continuing here.

Why does dynamic content cause CLS

The browser builds and renders your page based on what is in the initial HTML. Every element gets a position. Every element gets a size. The layout is set.

When JavaScript injects new content into the page after this initial render — especially above existing content — the browser has to recalculate the position of every element below the injection point. Everything shifts down by exactly the height of the injected content.

This is a layout shift. Google records it. It contributes to your CLS score.

The later the injection happens, the worse the CLS impact. An ad that loads 3 seconds into a page visit — after the user has started reading — causes a much more jarring shift than one that loads in the first 500ms.

The key insight: the browser cannot prevent a shift it did not know was coming. If the initial HTML has no placeholder for a 250px ad unit, the browser allocates no space for it. When the ad loads, a shift is unavoidable.

The fix is always to tell the browser in advance how much space to reserve.

Fix 1: Ad slots — always reserve space in advance

Advertising is the single biggest source of dynamic CLS on the web. Ad networks load asynchronously by design — the ad content arrives after the page has already rendered.

The problem is not the asynchronous loading. The problem is that most ad implementations give the ad container zero height before the ad loads:

<!-- Bad — zero height container causes shift when ad loads -->
<div id="ad-slot-header">
  <!-- Ad script injects a 250px banner here -->
</div>

When the ad loads, the container expands from 0px to 250px and everything below shifts down.

The fix: min-height on every ad container

Give every ad container a minimum height matching the largest ad unit that will be served in that slot:

<div
  id="ad-slot-header"
  style="min-height: 90px; width: 728px;"
  aria-label="Advertisement"
>
  <!-- Ad script -->
</div>

/* Or in your stylesheet */
#ad-slot-header {
  min-height: 90px; /* leaderboard height */
  width: 728px;
  display: flex;
  align-items: center;
  justify-content: center;
}

/* Mobile — different ad size */
@media (max-width: 768px) {
  #ad-slot-header {
    min-height: 50px; /* mobile banner height */
    width: 320px;
  }
}

Standard ad unit heights to use as min-height values:

Use min-height rather than height — if the ad network serves a smaller unit than expected, the container shrinks gracefully instead of leaving a large blank gap.

Google AdSense implementation

For Google AdSense specifically, use the data-ad-height attribute alongside a CSS minimum height:

<ins
  class="adsbygoogle"
  style="display:block; min-height: 90px;"
  data-ad-client="ca-pub-XXXXXXXXXX"
  data-ad-slot="XXXXXXXXXX"
  data-ad-format="auto"
  data-full-width-responsive="true"
>
</ins>
<script>
  (adsbygoogle = window.adsbygoogle || []).push({});
</script>

For responsive AdSense units where you do not know the exact ad height in advance, use a min-height of 100px as a safe default. This covers the most common ad sizes and prevents zero-height collapse.

Google Ad Manager (GAM) implementation

For publishers using Google Ad Manager with defined line items:

googletag.cmd.push(function() {
  // Define the slot
  var slot = googletag.defineSlot(
    '/NETWORK_ID/ad-unit',
    [[728, 90], [970, 90]],
    'ad-slot-header'
  );

  // Reserve space before ad loads
  googletag.pubads().addEventListener('slotRequested', function(event) {
    var slotDiv = document.getElementById(event.slot.getSlotElementId());
    slotDiv.style.minHeight = '90px';
  });

  slot.addService(googletag.pubads());
  googletag.pubads().enableSingleRequest();
  googletag.enableServices();
  googletag.display('ad-slot-header');
});

Fix 2: Cookie consent banners — use fixed or sticky positioning

Cookie consent banners are a legal requirement for most websites serving EU users. They are also one of the most common CLS causes because most implementations inject the banner above the page content after load.

The wrong implementation

// Bad — inserts banner at top of body, pushing all content down
document.body.insertBefore(cookieBanner, document.body.firstChild);

This pushes the entire page down by the height of the banner — typically 60–120px. Every element on the page shifts. CLS score spikes.

Fix: position: fixed or position: sticky

The correct approach is to overlay the banner on top of existing content rather than pushing it:

.cookie-banner {
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
  z-index: 9999;
  background: #1a1a2e;
  padding: 1rem 2rem;
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 1rem;
}

A position: fixed banner, anchored to the bottom of the viewport, overlays existing content. It does not push anything. No layout shift occurs.

If your banner must appear at the top of the page (some legal requirements specify this), use position: fixed; top: 0 and add padding-top to your <body> In the initial CSS, so the banner does not overlap your header:

/* In your initial CSS — reserve space for the banner */
body {
  padding-top: 70px; /* match banner height */
}

.cookie-banner {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  height: 70px;
  z-index: 9999;
}

Because the padding-top In the initial CSS (not injected by JavaScript), the space is reserved from the start. No shift occurs when the banner appears.

For third-party cookie consent tools

Most major cookie consent platforms (Cookiebot, OneTrust, Osano, CookieYes) have a positioning setting in their dashboard. Look for:

• Display position: Set to "Bottom" or "Bottom bar" rather than "Top banner."
• Display type: Set to "Banner" with fixed positioning rather than "Push content."
• Animation: Disable slide-in animations that cause content to move

If your cookie consent tool does not support fixed positioning, contact their support — it is a standard feature in 2026, and any tool that forces a layout-shifting implementation should be replaced.

Fix 3: Chat widgets — anchor to corner, not content flow

Chat widgets (Intercom, Drift, Tidio, Crisp, LiveChat) are one of the most common sources of unexpected CLS. The default implementation for most chat platforms injects the widget launcher button into the page flow — causing a shift when it loads.

The correct implementation

All modern chat platforms support a launcher button anchored to a fixed corner of the viewport. This is always the correct implementation for CLS:

/* Most chat platforms inject their own wrapper — override if needed */
#chat-widget-container,
.intercom-launcher,
.drift-widget-container,
#tidio-chat {
  position: fixed !important;
  bottom: 24px !important;
  right: 24px !important;
  z-index: 9998 !important;
}

For Intercom specifically, set the launcher position in your Intercom settings:

window.intercomSettings = {
  app_id: 'YOUR_APP_ID',
  alignment: 'right',
  horizontal_padding: 24,
  vertical_padding: 24,
};

This positions the launcher in the bottom-right corner with fixed positioning — no content shift.

Delay loading chat widgets until interaction

For the maximum performance impact, delay loading the chat widget entirely until the user first interacts with the page. Most users who visit your site never open the chat widget — why make all of them pay the CLS and INP cost of loading it?

function loadChatWidget() {
  // Intercom example
  (function(){
    var w = window;
    var ic = w.Intercom;
    if (typeof ic === "function") {
      ic('reattach_activator');
      ic('update', w.intercomSettings);
    } else {
      var d = document;
      var i = function(){ i.c(arguments); };
      i.q = [];
      i.c = function(args){ i.q.push(args); };
      w.Intercom = i;
      var l = function(){
        var s = d.createElement('script');
        s.type = 'text/javascript';
        s.async = true;
        s.src = 'https://widget.intercom.io/widget/YOUR_APP_ID';
        var x = d.getElementsByTagName('script')[0];
        x.parentNode.insertBefore(s, x);
      };
      l();
    }
  })();

  // Remove listeners after loading
  ['mousedown', 'touchstart', 'keydown', 'scroll'].forEach(event => {
    document.removeEventListener(event, loadChatWidget);
  });
}

// Load only after first interaction
['mousedown', 'touchstart', 'keydown', 'scroll'].forEach(event => {
  document.addEventListener(event, loadChatWidget, { passive: true });
});

This pattern eliminates the CLS impact entirely for users who do not interact with the chat widget — which is the majority of your visitors. It also improves INP and LCP since one fewer third-party script loads on the critical path. For more on how third-party scripts affect performance, see how to eliminate render-blocking resources.

Fix 4: Promotional and announcement bars

Promotional bars — "Free shipping on orders over $50", "Sale ends tonight", "Download our app" — are one of the most common CLS causes on e-commerce sites. They are almost always injected by JavaScript after page load, above the header, pushing the entire page down.

The wrong approach

// Bad — inserts promo bar above header after page load
const promoBar = document.createElement('div');
promoBar.className = 'promo-bar';
promoBar.innerHTML = 'Free shipping on orders over $50';
document.body.insertBefore(promoBar, document.body.firstChild);

Fix 1: Include the bar in the initial HTML

The most reliable fix is to include the promotional bar in your initial HTML — not injected by JavaScript:

<!-- In your HTML, before the header -->
<div class="promo-bar" id="promo-bar">
  Free shipping on orders over $50
  <button onclick="closePromoBar()">×</button>
</div>

<header>
  <!-- your header content -->
</header>

The browser knows the promo bar exists from the start. It allocates the correct space. No shift occurs.

For bars that need to be hidden for returning users (who already dismissed it), use a cookie check server-side to conditionally include or exclude the bar from the HTML — rather than showing it to everyone and hiding it client-side after a cookie check.

Fix 2: Reserve space with CSS if JavaScript injection is unavoidable

If you are using a third-party tool that forces JavaScript injection (some e-commerce apps and marketing platforms), reserve the bar's space in your initial CSS:

/* Reserve space for promo bar before it loads */
body {
  padding-top: 48px; /* match promo bar height */
}

.promo-bar {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  height: 48px;
  z-index: 100;
  background: #1a1a2e;
  color: white;
  display: flex;
  align-items: center;
  justify-content: center;
}

The padding-top: 48px on the body is in the initial CSS — it reserves the space from the very first render. When the promo bar loads into the fixed position, nothing shifts.

Fix 5: Third-party embeds — YouTube, Twitter, maps

Third-party embeds — YouTube videos, Twitter/X posts, Google Maps, Instagram posts, Spotify players — all load inside <iframe> elements. If those iframes do not have reserved dimensions, the container starts at zero height and expands when the embed loads.

YouTube embeds

The default YouTube embed code does not include explicit dimensions in a way that prevents CLS:

<!-- Default YouTube embed — causes CLS -->
<iframe
  src="https://www.youtube.com/embed/VIDEO_ID"
  frameborder="0"
  allowfullscreen
></iframe>

The correct implementation uses aspect-ratio CSS:

<div class="video-container">
  <iframe
    src="https://www.youtube.com/embed/VIDEO_ID"
    title="Video title"
    frameborder="0"
    allowfullscreen
    loading="lazy"
  ></iframe>
</div>

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
  position: relative;
}

.video-container iframe {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

The .video-container always reserves the correct 16:9 space. When the iframe loads inside it, there is no layout shift.

Lazy loading YouTube embeds (performance bonus)

For YouTube embeds below the fold, use a facade pattern — show a static thumbnail until the user clicks to play. This eliminates the iframe entirely until it is needed:

<div
  class="youtube-facade"
  data-video-id="VIDEO_ID"
  style="aspect-ratio: 16/9; cursor: pointer; position: relative;"
>
  <img
    src="https://img.youtube.com/vi/VIDEO_ID/maxresdefault.jpg"
    width="1280"
    height="720"
    alt="Video title"
    loading="lazy"
  >
  <button class="play-button" aria-label="Play video">▶</button>
</div>

<script>
document.querySelectorAll('.youtube-facade').forEach(facade => {
  facade.addEventListener('click', function() {
    const videoId = this.dataset.videoId;
    const iframe = document.createElement('iframe');
    iframe.src = `https://www.youtube.com/embed/${videoId}?autoplay=1`;
    iframe.allow = 'autoplay; encrypted-media';
    iframe.allowFullscreen = true;
    iframe.style.cssText = 'position:absolute;top:0;left:0;width:100%;height:100%;';
    this.innerHTML = '';
    this.appendChild(iframe);
  });
});
</script>

This facade pattern provides zero CLS (static image with known dimensions), faster LCP (no YouTube iframe on initial load), and better INP (no YouTube JavaScript blocking the main thread). The iframe only loads when the user explicitly clicks to play.

Twitter/X embeds

Twitter embeds are notoriously bad for CLS because their JavaScript resizes the iframe after the tweet content loads. The fix is to set a minimum height on the embed container:

<div style="min-height: 250px;">
  <blockquote class="twitter-tweet">
    <a href="https://twitter.com/user/status/TWEET_ID"></a>
  </blockquote>
  <script async src="https://platform.twitter.com/widgets.js"></script>
</div>

A min-height: 250px covers most tweet heights. The container reserves space before the Twitter JavaScript resizes the iframe.

Google Maps embeds

For Google Maps iframes, always use the aspect-ratio approach:

<div style="aspect-ratio: 16/9; width: 100%;">
  <iframe
    src="https://www.google.com/maps/embed?pb=..."
    width="100%"
    height="100%"
    style="border:0;"
    allowfullscreen
    loading="lazy"
    referrerpolicy="no-referrer-when-downgrade"
  ></iframe>
</div>

Fix 6: Newsletter and pop-up forms

Newsletter signup forms, exit-intent popups, and upsell modals are a less obvious but common source of CLS — particularly when they are injected into the content flow rather than displayed as overlays.

Forms injected into content

Some email marketing tools (Mailchimp, ConvertKit, ActiveCampaign) inject inline forms into the page content. If the form loads after the initial render and is inserted above existing content, it causes a shift.

Fix: Use their hosted form embed with a fixed-height container:

<!-- Reserve space for the form before it loads -->
<div style="min-height: 180px;" id="newsletter-form-container">
  <!-- Email marketing platform injects form here -->
</div>

Popup modals and overlays

Popup forms should always be used position: fixed with a backdrop overlay. They should never push page content:

.popup-overlay {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  background: rgba(0, 0, 0, 0.5);
  z-index: 9999;
  display: flex;
  align-items: center;
  justify-content: center;
}

.popup-modal {
  background: white;
  padding: 2rem;
  border-radius: 8px;
  max-width: 500px;
  width: 90%;
}

A The position: fixed overlay sits on top of the page content. Nothing shifts. Zero CLS contribution.

Platform-specific implementation

WordPress is where dynamic content CLS is most prevalent — advertising plugins, pop-up plugins, cookie consent plugins, and chat widget plugins all compete to inject content into your pages.

For ad plugins (Ad Inserter, Advanced Ads, WP AdCenter): All major WordPress ad plugins support custom CSS on ad containers. Add min-height to every ad placement in the plugin settings.

For cookie consent plugins (Cookiebot, GDPR Cookie Consent, Cookie Notice): In the plugin settings, set the banner position to "Bottom" or enable "Fixed position". Avoid "Top bar" settings that push content down.

For popup plugins (Popup Maker, OptinMonster, Elementor Popups): Ensure all popups use position: fixed with a full-screen overlay. Never use "Push content" or "Slide down" animations that shift page content.

For WooCommerce notifications: WooCommerce's default "added to cart" and stock notices can cause CLS. Override their positioning:

.woocommerce-notices-wrapper {
  position: fixed;
  top: 20px;
  right: 20px;
  z-index: 9999;
  max-width: 350px;
}

Shopify's app ecosystem is the primary source of dynamic CLS on Shopify stores. Every app that injects a banner, bar, widget, or notification is a potential CLS source.

For announcement bars: Move the announcement bar code from JavaScript injection to your theme.liquid file directly. Include it in the initial HTML:

{%- if section.settings.show_announcement -%}
  <div class="announcement-bar">
    {{ section.settings.announcement_text }}
  </div>
{%- endif -%}

For app-injected content: Go to your Shopify admin → Apps → and review each app's display settings. For any app that adds a bar, banner, or widget:

1. Check if the app has a "position" or "display" setting
2. Set it to fixed/overlay rather than inline/push
3. If no such setting exists, add CSS overrides in your theme's CSS file

For Shopify's cookie consent banner: The built-in banner (required in some markets) uses fixed positioning by default — no changes needed. Third-party cookie apps may need positioning overrides.

For Next.js applications, dynamic content injection is typically handled through React state and conditional rendering. The CLS risk comes from components that render differently on the server versus the client (hydration mismatch) or components that load data after mount.

For ads in Next.js:

function AdSlot({ slotId, minHeight = 90 }) {
  return (
    <div
      id={slotId}
      style={{
        minHeight: `${minHeight}px`,
        display: 'flex',
        alignItems: 'center',
        justifyContent: 'center'
      }}
    >
      {/* Ad script injected here */}
    </div>
  );
}

For cookie banners in Next.js:

'use client';
import { useState, useEffect } from 'react';

export function CookieBanner() {
  const [show, setShow] = useState(false);

  useEffect(() => {
    // Check cookie consent after mount (client-side only)
    if (!localStorage.getItem('cookie-consent')) {
      setShow(true);
    }
  }, []);

  if (!show) return null;

  return (
    <div style={{
      position: 'fixed',
      bottom: 0,
      left: 0,
      right: 0,
      zIndex: 9999,
      background: '#1a1a2e',
      padding: '1rem 2rem',
    }}>
      We use cookies.
      <button onClick={() => {
        localStorage.setItem('cookie-consent', 'true');
        setShow(false);
      }}>
        Accept
      </button>
    </div>
  );
}

The position: fixed; bottom: 0 ensures the banner overlays content rather than pushing it. The useEffect ensures the consent check only runs client-side — preventing hydration mismatches.

How to measure your CLS improvement

After implementing these fixes, verify the improvement:

Immediate verification: Chrome DevTools

1. Open Chrome DevTools → Rendering panel
2. Enable Layout Shift Regions
3. Reload the page and interact with it
4. Blue flashes indicate layout shifts — these should be gone or significantly reduced

Lab verification: PageSpeed Insights

Run PageSpeed Insights on your key pages before and after. The CLS score in the lab data section should decrease. Check the "Avoid large layout shifts" diagnostic — the contributing elements should be resolved.

Field data verification: Google Search Console

After deploying your fixes, check Google Search Console → Core Web Vitals in 28–35 days. The CLS report should show improvement across the affected URL groups. Field data takes time to update because it is averaged over a rolling 28-day window.

For a broader understanding of how CLS fits into your overall performance picture, the complete Core Web Vitals guide covers all three metrics and their interdependencies.

Dynamic ads and embeds CLS checklist

How does this connect to your other Core Web Vitals

Fixing dynamic CLS does not just improve your CLS score. It has knock-on effects across all three vitals.

Dynamic CLS → LCP: Many ad networks and third-party scripts that cause CLS also delay your LCP by blocking the main thread during load. Deferring these scripts — as recommended for chat widgets and promo bars — directly improves LCP. See what is a good LCP score to understand how third-party scripts affect your LCP timing.

Dynamic CLS → INP: Chat widgets, popup scripts, and ad networks that run JavaScript on user interactions are major INP contributors. Delaying their load until after page interaction — as shown in the chat widget section — removes their JavaScript from the critical interaction path. For the full picture on INP and JavaScript, see how to fix slow server response time, which covers how server-side delays compound third-party script issues.

Dynamic CLS → combined score: Google's Page Experience signal requires all three Core Web Vitals to pass. A site with good LCP and INP but failing CLS still gets a poor Page Experience signal. Dynamic content fixes are often the final step to getting all three metrics green simultaneously. For the image dimension fixes that should precede this article's fixes, see image and video size attributes to fix CLS.

And for everything before that — the foundational performance fixes, including server response time, LCP preloading, and render-blocking resources — the complete Core Web Vitals guide covers the full picture in one place.

Frequently asked questions

Q1. Why do ads keep causing CLS even after I add min-height to the container? 

The most common reason is that the ad network is inserting content above the reserved container — not inside it. Check your ad implementation and ensure the ad script is injecting into the correct container element. Also, check that your min-height CSS is not being overridden by the ad network's own styles — use !important if necessary or increase specificity.

Q2. Does Google penalise sites for showing cookie banners? 

No. Google explicitly states that cookie consent banners shown in response to legal requirements do not negatively affect Page Experience scores — as long as the banner uses position: fixed and does not cause a layout shift. The CLS impact of a cookie banner is what affects your score, not the banner itself.

Q3. My chat widget provider says their widget does not cause CLS. Why is PageSpeed Insights still flagging it? 

Many chat widget providers have updated their launchers to use fixed positioning but still inject a zero-height placeholder element into the page flow. Check for this placeholder in Chrome DevTools Elements panel — it may be invisible but still contributing to layout calculations. Override its positioning with CSS or contact the provider about removing it.

Q4. Can I use position: absolute instead of position: fixed for overlays? 

position: absolute positions elements relative to their nearest positioned ancestor — not the viewport. It can still cause a layout shift if the ancestor container changes size. Use position: fixed for all overlays that should not affect page layout — cookie banners, chat widgets, popups, and notification toasts.

Q5. How do I handle CLS from ads on mobile vs desktop when different ad sizes are served? 

Use responsive CSS with breakpoints to set different min-height values for each viewport size, matching the ad unit sizes served at each breakpoint. Test both desktop and mobile separately in PageSpeed Insights — Google scores them independently, and mobile ad sizes are often different from desktop.

Q6. My promo bar is managed by a third-party marketing tool, and I cannot change its code. What can I do? 

If you cannot modify the injection code, use a CSS override in your main stylesheet to apply position: fixed and reserve the correct space  <body> with padding-top. Load this CSS as early as possible — ideally, inline in your <head> — so the space is reserved before the marketing tool injects the bar.

Q7. Does lazy loading iframes prevent CLS?

loading="lazy" on iframes prevents them from loading until they enter the viewport — but it does not prevent CLS if the iframe container has no reserved dimensions. Always combine loading="lazy" with an aspect-ratio container. The lazy loading handles performance. The aspect-ratio handles CLS.

Summary

Dynamic ads, cookie banners, chat widgets, promotional bars, and third-party embeds cause CLS because they inject content into the page after the initial render without reserved space. The fix is always the same: tell the browser in advance how much space to reserve.

The five-fix priority order:

1. Ad slots — add min-height matching the largest expected ad unit to every container
2. Cookie banners — switch to position: fixed bottom positioning
3. Chat widgets — enable corner anchoring and delay loading until first user interaction
4. Promotional bars — include in initial HTML rather than injecting via JavaScript
5. Third-party embeds — wrap all iframes in aspect-ratio containers

Once dynamic content CLS is resolved alongside image and video dimension fixes, your CLS score should be in the Good range for most sites. If it is still failing, check for web font swaps and layout-affecting animations — the remaining CLS causes are covered in the complete Core Web Vitals guide.

Hardeep Singh

Hardeep Singh is a tech and money-blogging enthusiast, sharing guides on earning apps, affiliate programs, online business tips, AI tools, SEO, and blogging tutorials. About Author.