Banners Causing Layout Shift

Why bars do so much damage

A layout shift is scored on how much of the screen moves and how far. A strip only 40 pixels high does not sound like much, but when it is added above the header it moves the header, the hero image, the headline and the first paragraph: nearly the whole viewport. On a phone, those 40 pixels are a large fraction of the screen height. A single bar arriving late can use up most of the 0.1 allowance for a good CLS score.

Bars also sit where people are about to tap. A visitor reaching for the menu, the search box or the "Add to basket" button can end up pressing something else when a strip pushes it down. That is the real cost, and it is why these shifts are worth fixing even when the score is borderline.

The five patterns

The half-second rule and basket messages

Shifts that happen within 500 milliseconds of a click, tap or key press are left out of CLS, on the basis that the visitor asked for the change. People often assume that makes "added to basket" messages harmless. It does not, for two reasons.

1. The basket request is often slower than half a second. Most themes send the item to the server and wait for the reply before showing the message. On a phone connection that easily takes longer than 500 milliseconds, so by the time the message is inserted the grace period is over and the shift counts.
2. Follow-up changes are not tied to the click. A cart drawer that opens, then a recommendations strip that loads inside the page a second later, then a free delivery bar that updates its text: only the first of these may fall within the window.

The safe design is a message that never moves anything in the first place: a toast in a corner, a slide-in drawer or a fixed bar that sits over the page. Then it does not matter how long the server takes.

Pinning down which bar is moving the page

1. Run the CLS Debugger on the home page, a category page and a product page. If the elements it names are the header, the hero and the first headings, and the shift happens early, a bar at the top is the prime suspect.
2. In Chrome DevTools, record a reload in the Performance panel with slow throttling. Select the shift and look at what sits above the elements that moved.
3. Record a second session in which you add an item to the basket on a product page. Look for shifts starting more than half a second after the click; the Performance panel marks the click so you can measure the gap.
4. Repeat as a returning visitor: dismiss the bar, reload, and watch whether it appears briefly before disappearing.
5. Scroll the page slowly while recording, to catch a header that changes height as you scroll.

If you suspect a script or app is injecting the bar, view the page source (not the Elements panel). If the bar is not in the source, it is being added after load.

The fix, step by step

Code patterns

A fixed-height announcement bar

<div class="announce" role="region" aria-label="Announcements">
  <p>Free UK delivery on orders over £40 at Fernhill Pantry</p>
</div>

.announce {
  height: 2.5rem;
  display: flex;
  align-items: center;
  justify-content: center;
  overflow: hidden;
}
.announce p {
  margin: 0;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

A basket toast that floats over the page

<div class="toast" role="status" aria-live="polite"></div>

.toast {
  position: fixed;
  left: 50%;
  bottom: 1rem;
  transform: translate(-50%, 150%);
  transition: transform 0.25s ease;
}
.toast.is-visible { transform: translate(-50%, 0); }

Put the empty toast container in the HTML from the start and change only its text and class. Screen readers announce changes to an existing live region more reliably than a region that is added at the same moment as its message.

Hiding a dismissed bar before it is drawn

<head>
  <script>
    try {
      if (localStorage.getItem('announceClosed') === '1') {
        document.documentElement.classList.add('announce-closed');
      }
    } catch (e) {}
  </script>
  <style>.announce-closed .announce { display: none; }</style>
</head>

Because the script runs in the head before the body is drawn, the bar is never shown to someone who closed it. The try block stops a blocked storage setting from breaking the page.

Platform notes

• Shopify. Most themes include an announcement bar section rendered in the HTML, which is usually stable. Bars added by third-party apps are often injected by script after load. Theme cart notifications vary between themes: some insert a notice into the page, others open a drawer. Theme and app specifics are in CLS in Shopify.
• WordPress and WooCommerce. WooCommerce's standard "has been added to your basket" notice is part of the page when the product page reloads after adding. Themes and plugins that add to the basket without reloading often insert their own notices; check how they are positioned. Notification bar plugins differ in whether they push content or float. See CLS in WordPress.
• Custom sites and headless shops. You control the markup, so put the bar in the server-rendered HTML and use a single toast component for all feedback messages.

Cookie notices, newsletter prompts and age checks are a different family of late content, with their own fixes in fixing CLS from dynamic content insertion.

Keeping bars in check

• One place for site-wide messages. Give the marketing team a single announcement bar in the theme to edit, so they do not add a second one through an app or tag manager when they need a new promotion.
• One component for feedback. Basket confirmations, form success messages and errors that are not tied to a field should all use the same floating toast.
• Write short messages. Agree a character limit for bar messages that fits the narrowest phone on one line.
• Test before seasonal campaigns. Sales periods bring new bars, countdowns and banners. Run the CLS Debugger on the campaign pages before they go live.