Debouncing and Throttling

A single keystroke, scroll, or mouse movement doesn't sound like much. But a keyboard can fire a keystroke event every hundred milliseconds while someone types, and a scroll or mousemove can fire hundreds of times a second while someone drags. A handler that does real work — hitting an API, recalculating a layout — on every single one of those events is doing far more work than the situation calls for. Debouncing and throttling are the two standard ways to bring that firehose under control, and they solve different versions of the problem.

How to read this

Phase 1 lays out why the naive "run the handler on every event" approach is a real performance problem, with concrete examples. Phase 2 covers debounce — waiting for a pause before acting, the pattern behind every good search box. Phase 3 covers throttle — guaranteeing a maximum rate no matter how many events fire — and how to choose between the two.

The phases

1. The firehose problem — why running a handler on every event is a real performance problem.
2. Debounce: wait for a pause — the search-box pattern and the timer-reset idea.
3. Throttle: cap the rate — the scroll-handler pattern, and choosing between debounce and throttle.

Phase 1: The firehose problem →