In a single-page app users stay on one document for many minutes and change views client-side, and the app's CLS is poor even though the initial load produces almost no shifts. How does CLS accumulate across a session like that, and how would you attribute a shift to the view that caused it?

## CLS belongs to the document, not the screen The metric accrues for as long as the document is alive. Nothing about a client-side navigation — `history.pushState()`, a router swapping components, a URL change with no request — ends the measurement or starts a new one. As far as the platform is concerned, a forty-minute session across twelve views is **one page**. For a multi-page site this distinction barely matters, because a real navigation creates a new document and a new measurement. For a single-page app it is the whole story: your initial load can be flawless and your score still poor, because the score is being set by something the user triggered twenty minutes in. ## What the session window does and does not soften Session windows keep this from being unbounded. Shifts group into windows that close after a one-second gap and cap at five seconds, and CLS reports the **largest** window. So a long session does not mechanically accumulate a worse score than a short one — only the worst single burst counts. The consequence is worth stating plainly: **one bad view transition defines the session**. If switching to the reports tab reflows the page badly, it does not matter that the other eleven views are perfect, and it does not matter whether the user visited that tab once or ten times. The headline number cannot distinguish those cases; only your own logging can. ## The 500 ms exemption is the blind spot Shifts within 500 ms of a discrete input — click, tap, key press — carry `hadRecentInput` and are excluded. In an SPA this cuts in an odd direction. A view transition that renders immediately after the click is forgiven, as it should be. But a transition that fetches data and lands 900 ms later is well outside the window and is scored in full, even though the user clicked and is expecting a change. The metric cannot tell "the user asked for this" from "content shoved itself in" once the causal link is that old. So the fastest transitions are also the ones the metric treats most generously — which happens to align incentives correctly, but it also means users will report jumpiness that your dashboard does not show, and vice versa. When users complain about movement your data says is clean, check whether those shifts are landing inside the exemption. ## Attribution: from a number to a component A session-level score is unactionable on its own. Collect the individual entries instead: ```js let route = location.pathname; // update this from your router const shifts = []; new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.hadRecentInput) continue; shifts.push({ value: entry.value, at: Math.round(entry.startTime), route, nodes: entry.sources.map((s) => s.node && s.node.tagName), }); } }).observe({ type: 'layout-shift', buffered: true }); ``` The pieces that matter: - **`sources`** — each entry lists the nodes that moved, with `previousRect` and `currentRect`. In the field you cannot ship DOM nodes to a server, so map them to something stable: a selector, a `data-component` attribute, or the component name from your own registry. - **`startTime`** — lets you reconstruct which shifts shared a session window and therefore which ones actually contributed to the reported value. - **your route at that moment** — the platform does not know your app has views, so you have to stamp it yourself, from the router, at the time the entry arrives. - **`buffered: true`** — picks up shifts that occurred before your observer registered, which matters for anything during startup. Google's `web-vitals` library ships an `attribution` build that packages most of this, giving you the largest shift source and the load state alongside the value. Use it rather than hand-rolling unless you need the per-route stamping it does not know about. ## Reporting from a long-lived page A session that never navigates never fires an unload you can rely on. Report on `visibilitychange` when `document.visibilityState` becomes `hidden` — that is the only event you can count on to fire on mobile — and send with `navigator.sendBeacon()` so the request survives the page being backgrounded. Sending only at the end also means the value you send is final; sending incrementally means you have to reconcile updates server-side, because CLS can rise at any moment. ## What to do with the answer Once shifts are attributed per route, the fixes are ordinary: the view whose skeleton is a different height from its real content, the panel that expands after its data arrives, the list that re-measures. The point of the exercise is that in an SPA nothing else will point you at them — the score is a single number covering a session that may have touched a dozen screens, and without per-shift logging you are guessing which one to open.