Scroll and Input Latency

• Long task already running — Runs to completion; it cannot be preempted. The tap has already happened and is waiting (Long Tasks).
• Tap queued (user is waiting) — This is the bulk of the perceived latency, and none of it is your handler.
• Event dispatch + handler — The part most people optimise. It is usually the smallest bar.
• Pixels the user sees — The user measures from the tap, not from the dispatch — the whole bar is their experience of "how fast is this".

Shortening the handler shortens one small bar. Breaking up the long task shortens the large one (Yielding and Scheduling).

window.addEventListener('scroll', () => {
  // forced synchronous layout, once per scroll event
  const top = content.getBoundingClientRect().top
  header.classList.toggle('is-stuck', top < 0)
})

// No scroll listener at all: the browser reports the crossing
const sentinel = document.querySelector('#top-sentinel')!
new IntersectionObserver(
  ([entry]) => header.classList.toggle('is-stuck', !entry.isIntersecting),
  { threshold: 0 },
).observe(sentinel)

The first version forces a layout inside a handler that fires more often than frames are produced, so the browser recomputes geometry it is about to recompute anyway — and it does so on the thread the scroll may be waiting on. IntersectionObserver computes the same answer off the critical path and delivers it as a callback only when the answer changes, so the common case costs nothing at all. Where the effect is purely visual, position: sticky removes even the callback.

1let latest = 0
2let queued = false
3 
4window.addEventListener(
5  'scroll',
6  () => {
7    latest = window.scrollY        // a read the browser already has: no layout forced
8    if (queued) return
9    queued = true
10    requestAnimationFrame(() => {
11      queued = false
12      applyEffect(latest)          // runs at most once per frame
13    })
14  },
15  { passive: true },
16)

Two things are doing the work here: passive: true keeps the compositor from waiting on this listener at all, and the frame-callback gate collapses many events into one visual update. Note what is *not* here — no getBoundingClientRect(), because reading it inside the handler would force the layout this pattern exists to avoid.