Within a single session window, multiple small shifts and one large shift are treated identically by the math: each individual shift’s score (impact fraction times distance fraction) is summed with every other shift’s score in that same window, and the window’s total is what counts toward CLS. The algorithm has no separate penalty or leniency for “many small” versus “one big”; it simply adds. What actually determines the final CLS value is which session window (the worst one, by Chrome’s official definition) has the highest cumulative sum, not how the shifts within it are distributed.
Mechanism: session windows and the impact/distance fraction formula
Cumulative Layout Shift, as defined by Chrome’s rendering team and documented on web.dev, is built from two layers: an individual layout shift score, and a windowing method that groups individual shifts into “session windows” before summing.
Individual shift score. Each unexpected layout shift produces a score equal to:
layout shift score = impact fraction × distance fraction
The impact fraction is the proportion of the viewport affected by the shift, i.e. the union of the visible areas of all unstable elements in the frame before and after the shift, divided by the total viewport area. The distance fraction is the greatest distance any unstable element moved (horizontally or vertically) in that shift, divided by the largest viewport dimension (width or height, whichever is greater). Multiplying these two gives a single shift’s contribution. This formula is Google’s actual documented definition, not an approximation; it deliberately weights shifts by both how much of the screen was disturbed and how far things moved, so a tiny element jumping the full height of the viewport and a huge element shifting by one pixel can, in principle, produce comparable scores.
Session windows. Chrome doesn’t sum every shift across the entire page lifetime into one number. Instead, individual shift scores are grouped into session windows: a new window starts with the first shift after the page loads, and continues accumulating subsequent shifts as long as each new shift occurs within 1 second of the previous shift in that window, and the window’s total duration doesn’t exceed 5 seconds. If a shift occurs after a gap of more than 1 second from the last shift, or the current window has already run for 5 seconds, a new session window begins. This is Chrome’s actual windowing algorithm, introduced to replace the older “CLS since page load, summed forever” approach, specifically because that older approach unfairly penalized long-lived pages (like infinite-scroll feeds or long single-page apps) that would rack up an ever-growing score purely from being open a long time, even with well-behaved individual shifts.
CLS is the maximum session window. The page’s CLS value is defined as the largest cumulative score among all the session windows generated during the page’s lifecycle, not the sum of all windows and not the sum of all individual shifts on the page. This is the detail that answers the “many small vs. one large” question directly: whether a session window’s total comes from five 0.02-score shifts happening in quick succession, or one single 0.10-score shift, the resulting window score is mathematically identical (0.10 either way), and it’s judged purely on that window’s summed total relative to other windows on the page.
Practical implication: what this means for diagnosis and fixes
Because the windowing method sums within a window regardless of how the total is composed, a page with frequent small jank (say, a font swap here, an ad slot resizing there, a cookie banner sliding in) clustered within a second or two of each other can produce a session window score just as damaging as one dramatic reflow, if the small shifts land close enough together in time to fall into the same window. This matters practically in two ways.
First, when using DevTools or the web-vitals library’s attribution data to debug a real CLS problem, don’t stop investigating after finding “the big one.” If several unrelated small shifts occur within about a second of the largest shift, they’re being summed into the same window and inflating the reported score together. Fixing only the largest individual shift may leave the window’s total still elevated because of the smaller shifts riding alongside it.
Second, spacing matters as much as magnitude. If you can’t eliminate a shift outright (say, a third-party widget that unavoidably resizes after loading), delaying it so it falls more than 1 second after the prior shift, or ensuring it doesn’t fall within 5 seconds of a window that’s already accumulated other shifts, can put it into its own low-scoring window rather than compounding an existing one. This isn’t a trick to game the metric; it reflects genuinely better user experience, since shifts spread out over time and isolated from each other are less jarring to a real user than a cluster of shifts happening in rapid succession, which is presumably why the windowing method is designed around a 1-second gap threshold in the first place.
The practical takeaway for anyone auditing CLS: look at session windows as the unit of analysis, not individual shifts and not raw page-lifetime totals. The web-vitals library’s attribution build exposes the specific shifts contributing to the largest window Chrome measured for that page load, which is the correct level to inspect, since that’s the number Chrome Core Web Vitals reporting (and by extension PageSpeed Insights and the Search Console report) is actually built from.
A hypothetical illustration
Hypothetically, imagine a news site, call it Coastal Herald, auditing a poor CLS score on its article template. Suppose the attribution data shows one dramatic shift, a late-loading hero image pushing the byline down, scoring 0.09, and the team fixes it by reserving the image’s dimensions in advance, expecting CLS to drop close to zero. If, hypothetically, the actual CLS score barely improves, checking the session window more closely might reveal that within the same one-second window as the hero-image shift, three smaller shifts were also occurring nearly simultaneously, a font swap nudging the headline, an ad slot resizing, and a “subscribe” banner sliding in, together contributing another 0.07 to that same window’s total. Because Chrome sums every shift within a window regardless of individual size, fixing only the large, obvious shift left the window’s cumulative score still elevated. Only after addressing all four contributing shifts, or spacing the smaller ones outside the 1-second window entirely, would Coastal Herald’s CLS score reflect the improvement the team expected from fixing “the big one.”
