Layout shift during scrolling: a blind spot.

Classic layout shift measurement looks at the page-load window; shifts occurring after the user starts scrolling are invisible in that window.

This page is not theory but the record of a defect found by measurement on this site. And more instructive than the defect itself is how it was found — because no general audit tool was showing it.

The situation: the layout shift measured during page load was very close to zero, and every tool gave green. But when the user started scrolling, a visible shift occurred as a pinned section was released. Two truths held at once: the metric was good and the experience was bad.

Why it does not show

Audit tools open the page, wait for it to load, and report the shift accumulated in that window. They do not scroll — because scrolling is a user behavior and simulating it is not a standard step. No shift triggered by scrolling therefore enters that measurement.

In field data these shifts do show, because real users scroll. But field data is aggregate and delayed; it does not say which section a shift came from. So the problem surfaces as a number in the field data, never surfaces in the lab measurement, and a diagnostic gap remains in between.

The gap is not a missing tool but a missing question. The tool was asking “does it shift while loading” and answering correctly. Nobody was asking “does it shift while scrolling.”

The metric was good and the experience was bad; both were true because the metric was not asking that question.

Pinned sections

The source of the shift was pinning behavior synchronized with scrolling. A section is held fixed on screen, its content changes as scrolling continues, and when the section is released it returns to the page flow. At that moment of return, the space it occupies is recomputed and the content below it shifts.

This is a classic side effect of motion libraries and is born almost always of the same cause: the pinning is done by removing the element from the document flow and putting it back. The alternative method — leaving the element in the flow and moving it only with the transform property — never touches the layout and produces no shift.

The fix went in that direction and was locked with two separate guards. The first measures the problem directly: the shift at the moments of pinning and release must stay under 0.01. The second is more general: across the whole scroll, the worst window computed with Google’s session-window logic must stay under 0.08 — leaving a deliberate margin below Google’s good threshold of 0.1.

How to measure it

Setting up this measurement needs no special tool; the browser’s own layout shift observer can be used. The difference is in when the measuring happens: not in the page-load window but during scrolling.

1. Open the page and wait for it to load — measure the initial shift separately.
2. Reset the observer — from here on, what counts is scroll shift.
3. Scroll programmatically — in steps close to real user speed, across the whole page.
4. Split the shifts into windows — with Google’s session-window logic; take the worst window.
5. Bind to a threshold — set a target below the official threshold so a regression shows early.
6. Run it on every deployment — measuring once and moving on breaks at the next motion addition.

The fourth item is critical: the window logic being identical to Google’s own guarantees the test really measures the same thing. A test measuring the total shift goes needlessly red on long pages and gets ignored after a while.

The general lesson

What this case really teaches is not the pinning technique but the audit method. A green report is the answer to the questions asked — it says nothing about the questions not asked. And knowing which question a tool asks is the auditor’s responsibility.

The same pattern played out on this site’s accessibility side too: a contrast criterion was tested by no tool, and a real defect lived in that gap. Two cases in different fields, one lesson.

The practical consequence: read each measurement tool’s scope once, list the criteria it does not cover, and turn that list into your own tests. The gap general tools leave closes with project-specific guards — it closes no other way.

Similar blind spots

The pattern of this case is not limited to one metric, and other blind spots can be hunted with the same logic. The shared question: in which WINDOW is this metric measured, and what happens outside that window?

1. Interaction responsiveness — the measurement requires real interaction; it never shows in a test that interacts with nothing.
2. Long tasks — periodic work running after the page loads is absent from the load window.
3. Memory leaks — they accumulate in long sessions; a single page open shows nothing.
4. Scroll performance — frame drops occur only while scrolling.
5. Embedded content — resources loading on user interaction are absent from the first measurement.

What the five items share: all of them arise in real use and never show in a standard page-open test. It demonstrates once more the limit of automated auditing: the tool measures one scenario and stays silent about everything outside it.

On this site the shift during scrolling and the frame budget are measured by separate tests; both are questions standard tools do not cover. The frame budget thresholds derive from the sixty-frames-per-second target: the median under 12 milliseconds, the 95th percentile under 24.

A method suggestion to close: the most productive way to hunt blind spots on your own site is writing the real usage scenarios and asking which metric is measured at each step. The user opens the page, scrolls, presses a button, opens a layer, goes back — at each step, which tool measures what? The unmeasured steps are the list of blind spots, and that list turns directly into new tests.

A practical checklist

Turning this page into an audit step, here is what to check for measurement blind spots. The list is kept short because long lists do not get walked; six items fit in one sitting.

1. In which window is this metric measured?
2. What happens outside that window — scrolling, interaction, long sessions?
3. Does the tool interact with the page — if not, the interaction metrics are missing.
4. Was a real usage scenario written — at each step, which tool measures what?
5. Were the unmeasured steps listed — that list is the plan for new tests.
6. Was every defect found bound to a test?

The sixth item is the summary of how this site works: fixing a defect removes it once; adding a guard keeps it from returning.