A scroll listener on a long page calls getBoundingClientRect() on about forty elements on every scroll event, to decide which ones are on screen and to reposition a sidebar. Scrolling stutters, and batching the reads and writes only helps a little. What would you replace the measurement with, and why is that cheaper?

## Why the handler is the wrong shape, not just the wrong order Scroll events fire at a high rate, and everything in the handler competes with producing the next frame. Forty geometry reads per event is expensive even when they are perfectly batched, because the *quantity* of work is proportional to the number of elements and the frequency of scrolling — neither of which you control. Batching reads and writes is a real technique and it stops the per-iteration round trips, but it cannot make forty measurements free, and it does nothing about the frames where nothing actually changed. That is why the improvement is only partial, and why the next move is architectural: get out of the business of measuring during scroll. ## What IntersectionObserver replaces Any question of the form "is this element visible / has it come into view / how much of it is showing" is what `IntersectionObserver` exists for. You register targets once; the browser evaluates intersections as part of its own rendering work and invokes your callback only when a target crosses one of the thresholds you configured. Two consequences matter for performance: - **Scroll frames where nothing crosses a threshold cost you nothing.** No callback runs, no code executes. A measuring handler pays full price on every one of those frames. - **Your code never reads geometry.** Each entry already carries `boundingClientRect`, `intersectionRect`, `rootBounds` and `intersectionRatio`, computed by the browser at a moment when layout was clean. Reading those properties off the entry cannot force anything. `rootMargin` grows or shrinks the trigger area, which is how you start loading something 200 pixels before it appears; `threshold` accepts a list, so "half visible" and "fully visible" are separate callbacks rather than a computation you write. `root` lets you observe within a scrollable container instead of the viewport. ```js const io = new IntersectionObserver((entries) => { for (const entry of entries) { entry.target.classList.toggle('in-view', entry.isIntersecting); } }, { rootMargin: '100px', threshold: 0.25 }); document.querySelectorAll('.card').forEach((el) => io.observe(el)); ``` ## What ResizeObserver replaces The sibling pattern is code that measures a container on every scroll, resize, or animation tick to keep something in proportion. `ResizeObserver` calls you when an observed box actually changes size and hands you `contentRect` (plus `borderBoxSize` / `contentBoxSize`), so again you stop reading. Two cautions belong in a senior answer. First, it fires when the box changes, which includes changes *you* cause — writing a style inside the callback that resizes the observed element is how pages produce the "ResizeObserver loop completed with undelivered notifications" error, and the fix is to observe one element and mutate a different one, or to guard against writing the same value twice. Second, it is not a substitute for CSS: if the layout can be expressed in the layout engine, express it there. ## What CSS deletes outright Before reaching for any observer, ask whether the effect needs JavaScript at all. A sidebar that should stop at the top of the viewport is `position: sticky` with a `top` offset, and that removes the handler, the measurement and the write together. The cheapest measurement is the one nobody performs. ## When you still have to measure Be explicit about the limit, or the answer sounds like cargo cult. Observers are *event*-shaped: they tell you when something crossed a boundary. Effects that need a continuous value on every frame — a parallax offset, a progress bar bound to exact scroll position, an element that tracks another pixel-for-pixel — cannot be expressed as thresholds. There, keep one read per frame, take it once at a point in the frame where layout is clean, and drive everything from that single value; you have then reduced forty measurements per event to one per frame, which is the achievable win. Also note that scroll position itself (`window.scrollY`) is not the same class of problem as measuring forty elements — the cost you are attacking is per-element geometry, not knowing where the page is. ## Verifying the change Re-record the interaction. Success looks like scroll frames with no scripting entry at all on the frames where nothing crossed a threshold, and rendering work back to once per frame where something did. If the page still janks afterwards, the cost was never in the measurement, and the trace will now show you where it actually is.