No, this is a common but incorrect assumption. Cumulative Layout Shift measures unexpected layout shifts for elements that are within the viewport at the moment the shift occurs, at any point during the page’s lifecycle, not just shifts that happen in the initial above-the-fold view at load time. If a user scrolls down and a layout shift then happens within whatever is currently visible on their screen, that shift counts toward CLS exactly the same way an above-the-fold shift at initial load would. The metric is scoped to “whatever is currently in the viewport, whenever it happens,” not “the initial viewport only.”
Mechanism: what “layout shift” actually requires to count
Chrome’s official definition, documented on web.dev and in the underlying Layout Instability API specification, defines a layout shift as occurring whenever a visible element changes its start position between two rendered frames, without that change being the direct result of user interaction (an important separate carve-out; shifts within 500ms of certain user inputs are excluded as “expected”). Critically, the qualifying condition is about visibility at the time of the shift, not about position on the page relative to the very first viewport shown when the page loaded.
This means the Layout Instability API, which is what CLS is built on, continues observing and scoring shifts for the entire time the page is open, from initial navigation until the page is unloaded or backgrounded. If a user scrolls three screens down and an element in that now-visible region jumps because a late-loading image finally resolves its dimensions, or an injected ad slot expands, or a web font swap reflows nearby text, that shift is captured by the same API, contributes an individual layout shift score using the same impact-fraction-times-distance-fraction formula, and gets grouped into session windows the same way any other shift would, regardless of when in the session or where on the page it occurs.
The confusion likely comes from conflating CLS with Largest Contentful Paint, which genuinely is scoped mostly to the initial load experience (LCP specifically measures the render time of the largest visible element, essentially an above-the-fold-at-load-time concept for most pages), or from a looser mental model that “page experience metrics are about first impressions.” CLS doesn’t work that way by design; Google’s stated rationale for measuring shifts throughout the full page lifecycle, including post-scroll and post-interaction states, is that layout instability anywhere during a real user’s engagement with the page is a genuine usability problem (misclicks, lost reading position, disorientation), not just a first-impression cosmetic issue, so scoping the metric only to initial paint would miss most of what actually frustrates users on longer or more interactive pages.
Why the “initial viewport only” belief causes real measurement blind spots
If a team internalizes CLS as an initial-viewport-only metric, the practical consequence is that they’ll test and monitor only what’s visible without scrolling, typically using tools like Lighthouse in its default single-shot lab mode, which does capture some scroll-triggered behavior depending on how the test is run but is frequently used in a way that only exercises the first paint. This leads to real production CLS problems going undiagnosed: infinite-scroll feeds where newly loaded content pushes already-visible content upward once the user has scrolled well past the fold; below-the-fold ad units, embeds, or lazy-loaded images that reflow their containers after the user has scrolled to them; and accordion/expand interactions elsewhere on the page whose reflow effects ripple into currently-visible regions outside the direct interaction target.
None of these would show up if you only ever check “does the page jump when it first loads,” but all of them are captured by the real CLS metric as computed by Chrome and reported through CrUX, PageSpeed Insights, and the Search Console Core Web Vitals report, because those tools are built on field measurement of actual user sessions that include scrolling and continued interaction, not just the first frame.
As a hypothetical example: imagine a hypothetical news site, “Site Q,” running an infinite-scroll article feed. Hypothetically, if a reader scrolled three screens down into the feed and a late-loading ad unit then expanded and pushed the article they were reading upward by a noticeable amount, that shift would be captured by the Layout Instability API and counted toward that session’s CLS exactly as if the same jump had happened at the very top of the page on initial load. A team that only tested Site Q’s homepage load in Lighthouse’s default single-shot mode, without scrolling through the feed, would likely miss this issue entirely, even though it’s fully counted in the real CrUX field data feeding Search Console’s Core Web Vitals report.
Practical implication: how to actually test for this correctly
Testing needs to include realistic scroll behavior, not just initial load. In DevTools’ Performance panel, record a session that includes scrolling through the full page (or at least through sections known to have dynamic or late-loading content), not just the initial paint, and look for Layout Shift markers appearing anywhere in that recording’s timeline, not only near the start. The web-vitals JavaScript library, run as real user monitoring in production, will naturally capture this correctly by default since it listens to the Layout Instability API for the full session, but if you’re spot-checking manually, make sure your manual test includes the same scroll and dwell behavior a real user would exhibit.
When auditing a page for CLS issues, explicitly check below-the-fold dynamic content as its own category: lazy-loaded images and iframes without reserved dimensions, infinite-scroll or “load more” content insertion points, and any embeds or widgets that render below the initial fold. Reserve space for all of these the same way you would for above-the-fold elements (via min-height, aspect-ratio, or explicit width/height attributes on images and iframes), since from the metric’s perspective there’s no structural distinction between an above-the-fold shift and a below-the-fold one; both are scored by the same formula, grouped by the same session-window logic, and both count fully toward the CLS value that Google surfaces in Core Web Vitals reporting.
