Fixing Janky Scroll Animations Caused by Forced Synchronous Layout in Scroll Handlers

The Problem

A scroll-linked animation — a parallax effect, a progress bar, a header that shrinks as the user scrolls — looks smooth in isolation, but the moment it's added alongside other elements on the page, scrolling starts to visibly stutter, especially on mid-range mobile devices. The animation logic itself isn't slow; the stutter comes from the browser being forced to recalculate layout synchronously, mid-frame, far more often than it needs to.

Why It Happens

Reading a layout property right after writing one forces a synchronous recalculation

Properties like offsetTop, getBoundingClientRect(), scrollHeight, or clientWidth require the browser to have up-to-date layout information to answer. If a scroll handler writes a style (e.g., sets transform or height) and then reads one of these properties in the same handler invocation — even for a different, unrelated element — the browser can't wait for its normal render cycle; it must flush pending layout changes and recompute immediately, right there in JavaScript. This is "forced synchronous layout," sometimes called layout thrashing.

Scroll events fire far more often than the animation actually needs

A plain scroll event listener fires many times per frame on some browsers, and by default runs on the main thread without any coordination with the browser's own paint schedule — every one of those firings that also triggers a layout read/write pair compounds the cost.

Multiple independent scroll-linked effects interleave their reads and writes

When several components each attach their own scroll listener, one component's write can force a layout recalculation that a completely unrelated component's read then benefits from (or gets blamed for) — the interleaving itself is what turns several individually-cheap operations into a very expensive one when it happens read-write-read-write instead of read-read-write-write.

The Fix

1. Batch all layout reads before any layout writes

// Bad: read, write, read, write — forces layout twice
const a = el1.getBoundingClientRect();
el1.style.transform = `translateY(${a.top * 0.5}px)`;
const b = el2.getBoundingClientRect();
el2.style.transform = `translateY(${b.top * 0.3}px)`;

// Good: all reads first, then all writes
const rectA = el1.getBoundingClientRect();
const rectB = el2.getBoundingClientRect();
el1.style.transform = `translateY(${rectA.top * 0.5}px)`;
el2.style.transform = `translateY(${rectB.top * 0.3}px)`;

Grouping every read together and every write together means the browser only needs to compute layout once per frame, no matter how many elements are involved.

2. Drive the animation from requestAnimationFrame, not the raw scroll event

let ticking = false;
window.addEventListener("scroll", () => {
  if (!ticking) {
    requestAnimationFrame(() => {
      updateScrollAnimation();
      ticking = false;
    });
    ticking = true;
  }
});

This coalesces however many scroll events fired since the last frame into a single update, aligned with the browser's own paint cycle instead of running the read/write logic on every raw event.

3. Prefer transform/opacity-driven animation over properties that trigger layout

Animating transform and opacity can be handled by the compositor without triggering a full layout or paint at all, unlike animating top/left/width/height directly — reframing a scroll effect in terms of transforms removes most of the temptation to read layout-triggering properties in the first place.

4. Cache values that don't change during the scroll gesture

An element's total height or a fixed offset often doesn't change while the user is mid-scroll — measure it once (e.g., on resize or on mount) and reuse the cached value inside the scroll handler, instead of re-measuring it on every single frame.

Why This Works

None of these changes make the browser's layout engine faster — they reduce how many times it's forced to run outside its own schedule. Batching reads and writes lets one layout pass serve every element instead of one pass per element; requestAnimationFrame caps the update rate to what the display can actually show; and transform-based animation sidesteps layout recalculation for the parts of the effect that don't strictly need it.

Conclusion

Janky scroll-linked animations are almost never a sign the effect itself is too complex — they're a sign layout reads and writes are interleaved in a way that forces the browser to recompute layout far more often than once per frame. Batch reads before writes, drive updates through requestAnimationFrame, and animate transform/opacity where possible, and the same effect runs smoothly even alongside other scroll-linked elements on the page.