Diagnosing CLS Beyond Images

The plain-language idea

You already know the classic CLS fix: reserve space for an image before it loads, usually with width/height or aspect-ratio. That fix handles maybe a third of real-world CLS. The rest comes from sources that don't look like "an image with no dimensions" at all:

• Web font swaps. A fallback font renders first (so text is visible immediately), then the real font finishes loading and replaces it. If the two fonts have meaningfully different character widths or line heights, the text reflows — pushing everything below it down or up. This connects directly to font-loading strategy, which is its own lesson later in this track.
• Dynamically injected content. A cookie consent banner, an ad slot, or a "recommended for you" widget that inserts itself into the page after the surrounding layout has already settled — pushing existing content down instead of having its space reserved from the start.
• Layout-property animations. CLS specifically measures unexpected shifts of existing content. An animation that changes top, left, width, or height moves the box on every frame, and if that motion displaces other elements on the page, each of those frames can register as a real layout shift. An animation that uses transform instead moves pixels visually without changing any other element's layout position at all — so it doesn't register on CLS, even though it looks similar to the eye.

See it in a real thing: a cookie banner with no reserved space

// Bad: the banner mounts after initial layout, pushing page content down
function App() {
  const [showBanner, setShowBanner] = useState(false);
  useEffect(() => {
    setShowBanner(true); // mounts on the client, after first paint
  }, []);
  return (
    <>
      {showBanner && <CookieBanner />}
      <PageContent />
    </>
  );
}

/* Better: reserve the banner's space up front with min-height,
   even before it's known whether it'll actually show */
.cookie-banner-slot {
  min-height: 64px;
}

If CookieBanner renders at the top of the page after PageContent has already painted, every pixel of PageContent shifts downward the instant the banner appears — a textbook unexpected layout shift, and one that has nothing to do with an unsized image. Reserving the slot's height ahead of time (even while the banner's actual content is still loading) means the shift never happens, because the space was already there.

What people usually miss

Watch out

• Font swaps cause layout shift only when the fallback and real font have different metrics — if the fonts are metrically similar (or a system font stack is used as the fallback), the swap can happen with zero visible shift. This is why "font metric overrides" (size-adjust, ascent-override, etc.) exist as a fix.
• transform-based animation genuinely doesn't count against CLS, because CLS only measures shifts of elements' layout boxes — animating transform changes what's painted on screen without moving any element's position in the layout, so nothing else reflows.
• The Chrome DevTools Performance panel has a "Layout Shift" track that flags exactly when a shift happened and highlights which elements moved, in the "Layout Shift Regions" experimental overlay — don't try to spot shifts by eye on a live page when this tooling exists.
• A shift that happens within 500ms of a genuine user interaction (like a tap that reveals more content) is excluded from CLS — the metric is specifically about unexpected shifts, not all shifts.

Why this matters in interviews

"We fixed all our unsized images but CLS is still bad — what else would you check?" is a real follow-up senior interviewers ask specifically to see if a candidate's CLS knowledge goes past the one obvious fix into fonts, injected content, and animation choices.