A page paints quickly, then a cookie-consent bar and a promo strip are injected at the top of the document a moment later, pushing the article down; the page's CLS is poor. Why does this pattern score so badly, and what would you change without removing either banner?

## Why top-of-document injection is the worst case A layout shift's score is driven by how much of the viewport moved and how far. Insert an element at the very top of the document flow and you have maximised the first factor by construction: **everything visible below it moves**. The unstable elements union to roughly the entire viewport, so the impact fraction sits near 1, and the score collapses to approximately the banner's height divided by the viewport's larger dimension. A 90 px bar on a phone is a substantial fraction of the screen — enough, on its own, to push a page past the commonly used 0.1 "good" guidance. Note the asymmetry with injecting *below* the fold: content added under the visible area moves nothing the user can see, and scores nothing. The problem is not injection, it is injection **above already-visible content**. ## Why two bars are worse than twice one bar Shifts less than a second apart fall into the same session window and their scores are summed. A consent bar at 800 ms and a promo strip at 1,300 ms are one burst, not two incidents. Worse, the second injection moves the same content again, from a position it had only just settled into — so you pay full impact twice. Staggering the injections further apart does not help the user at all; it only splits the score across windows, which is metric-gaming rather than a fix. ## Fix 1 — make the first layout correct The real defect is that the first layout the user saw was computed with information that later turned out to be wrong. The strongest fix is to have the information earlier. Consent state is usually in a cookie the server can read, so the server can emit the bar — or omit it — in the initial HTML. Then it is present in the very first frame, and there is no shift because there is no change. The same reasoning applies to promo strips driven by an experiment assignment: resolve the assignment server-side, or inline the decision in a blocking script in the document head, rather than letting a late client fetch rewrite the top of the page. ## Fix 2 — take it out of the flow When the decision genuinely cannot be made before paint, the next best answer is that the banner should not participate in layout at all. A `position: fixed` bar anchored to the bottom of the viewport overlays content instead of displacing it, so no element's start position changes and no shift is recorded. Bottom placement is also better UX on mobile — it is nearer the thumb and does not cover the headline — so this is rarely a sacrifice. If the bar must slide in, animate it with `transform: translateY(...)`, which moves pixels without moving layout and therefore scores zero. ```css .consent-bar { position: fixed; inset: auto 0 0 0; transform: translateY(100%); transition: transform 200ms ease-out; } .consent-bar[data-open='true'] { transform: translateY(0); } ``` ## Fix 3 — reserve the space, honestly The fallback is a placeholder of the banner's exact height rendered in the initial HTML, which the banner then fills. This works, and it is the right answer when the bar truly must sit in the flow at the top. Be clear-eyed about the cost: you have permanently spent that vertical space, above the fold, on something that may never appear. Reserve only when you expect the bar to appear for most users, and never guess the height — pin it with a fixed height on the container rather than letting the injected content define it. ## Third-party tags Often the injection is not yours: a tag manager, a consent vendor, or an ad script writes into the top of the page. The technique is the same but the enforcement is contractual — give the vendor a host container that you own, with a fixed height or fixed positioning, and require them to render inside it. If the vendor insists on writing directly to `document.body`, that is a procurement conversation, not a CSS one; measure the shift it causes and attribute it to that script by name. ## What not to do - **Do not delay the injection past the session window** to split the score. The user's experience is unchanged and you have made the jump happen later, when they are more likely to be mid-tap. - **Do not hide the bar behind a click** to claim the recent-input exemption. Shifts more than 500 ms after the input still count, and you have added a step for the user. - **Do not animate height or margin** to soften the entrance. Every animated frame that displaces content is its own layout shift, so a smooth 300 ms height animation produces a stream of shifts rather than one — softer to look at, no cheaper to score, and often worse. ## The rule to take away Never insert into the flow above content the user can already see. Either the content is in the first layout, or it lives in a layer that does not participate in layout.