Throttle

Some input arrives as a stream rather than as a decision. A scroll produces an event for every few pixels, a drag one for every pointer sample, a resize one for every frame of the window being dragged, and none of those individual events is interesting: what matters is where things ended up, sampled often enough to look continuous. Throttling puts a floor under the interval between responses. The first event is usually answered immediately (the leading edge) and everything arriving inside the interval is absorbed, with one more answer after the interval so the last value is not lost (the trailing edge). The promise is a cadence, and the guarantee is that expensive work happens a bounded number of times per second no matter how generous the browser is with events.

That is the opposite bargain from debouncing, which waits for a gap and answers once when the input stops. A debounced handler attached to a scroll that never stops never runs at all, and a throttled handler attached to a search field answers with values the person was only passing through. Bursts with an end to them want debounce; continuous streams want throttle. It is worth saying out loud which one a piece of code is, because the two are routinely named as though they were interchangeable and the bugs they cause look nothing alike.

Choose the interval from what the response costs. Anything that paints should be throttled to the frame rather than to a clock, which means requestAnimationFrame: at 60 hertz a timer set to 16 milliseconds and a frame callback look similar and only one of them is actually aligned with when the screen is redrawn. Work that hits the network or does real computation wants something in the range of 100 to 250 milliseconds. Always keep the trailing call, or the readout is left holding a position the reader has already scrolled past. Cancel any pending call when whatever owns the handler is torn down, register scroll and pointer listeners as passive so the browser need not wait to see whether the event will be cancelled, and check what the platform already gives you: pointer events are coalesced by the browser, and getCoalescedEvents hands back the samples that were merged if you actually want them.

The failure mode is throttling something that has to feel immediate. A hover highlight or a drag preview capped at 200 milliseconds does not read as efficient, it reads as a laggy interface, and the fix is a shorter interval or a frame callback rather than a different technique. Watch out for the word appearing in two unrelated places, too: the server-side rate limit that answers with HTTP 429 is also called throttling, and it is someone else’s cap on your requests rather than your cap on your own work.