Certain browser events fire far more often than you want to act on them — typing, scrolling, resizing and mouse movement can trigger many times per second. Running expensive work on every single one janks the interface and wastes resources. Debouncing and throttling are the two classic techniques for handling floods of events gracefully, and developers often confuse which is which.
They solve the same broad problem in two distinct ways.
Debouncing: wait for the pause
Debouncing waits until the events stop before acting. It says, in effect, "do nothing until things have been quiet for a moment, then run once". The ideal example is a search box that queries as you type: you do not want a request on every keystroke, only once the user pauses, so debouncing fires a single action after typing settles.
The key property is that a continuous burst of events results in just one action, at the end of the burst.
Throttling: act at a steady rate
Throttling instead lets the action run at most once per interval, no matter how many events arrive. It says "run at a fixed maximum rate while things are happening". This suits continuous processes like reacting to scrolling, where you want regular updates during the activity, not one at the end, but also not one per pixel.
The distinction is timing: debouncing collapses a burst into one action after it ends; throttling spaces actions out evenly during the burst.
Choosing between them
Ask what you actually want. If you only care about the final state after activity settles — a search query, a resize handler that recomputes layout once — debounce. If you want regular responsiveness during ongoing activity — scroll-driven effects, progress updates — throttle at a sensible rate.
Both are small techniques with a large impact on smoothness and efficiency. Knowing which fits the situation is the whole skill.
Building a debounce from scratch, and the one detail that is easy to get wrong
A debounce wraps a function so that it only actually runs after a specified quiet period has passed with no further calls, implemented with a single stored timer: every call clears whatever timer is currently pending and sets a fresh one, so a rapid burst of calls keeps resetting the delay and only the final call in the burst survives long enough for its timer to actually fire. The detail that trips up a naive first implementation is `this` binding and argument passing — a debounce wrapper has to correctly forward whatever arguments and calling context the most recent invocation used, not the first one in the burst, since it is specifically the final call's inputs that the caller actually cares about seeing take effect.
Building a throttle from scratch, and why it needs a different shape entirely
Where a debounce waits for silence, a throttle guarantees a function runs at most once per fixed time window regardless of how many calls arrive during it, which requires tracking the last time the function actually ran and comparing it against the current call — if enough time has passed, run immediately and record the new timestamp; if not, either drop the call entirely or, in a trailing-edge variant, schedule one more run for the end of the current window to make sure the very last call in a burst is not lost. This is a structurally different algorithm from debounce, not a parameter tweak on the same one, because the goal is fundamentally different: a debounce cares only about the end of a burst, while a throttle cares about maintaining a steady, bounded rate throughout the whole burst.
Leading edge versus trailing edge, and why some implementations offer both
A 'leading edge' debounce or throttle fires immediately on the first call and then withholds further calls for the specified window, which suits a use case where an instant first response feels responsive and any additional rapid repeats are what actually need suppressing — a button that should react instantly to the first click but ignore accidental double-clicks. A 'trailing edge' variant instead waits out the full window before firing, which suits a use case where only the final, settled state actually matters, like a search-as-you-type box where every intermediate keystroke's search is wasted work. Mature implementations, like the ones shipped in Lodash, expose both options because the two edge behaviors solve genuinely different problems, and picking the wrong one produces code that technically limits call frequency but still feels wrong for the specific interaction it is attached to.
Cancellation: the feature a naive implementation forgets entirely
A debounced or throttled function attached to a component that gets unmounted or destroyed before its pending timer fires will still fire anyway unless the wrapper explicitly exposes a way to cancel that pending invocation, which is exactly the kind of bug that shows up as a confusing error about updating state on an unmounted component, or a network request firing well after the user has navigated away from the page that triggered it. A production-grade debounce or throttle implementation exposes a `.cancel()` method specifically so calling code can clean up a pending invocation at the moment it is no longer wanted, rather than leaving it to fire regardless of whether anything is still around to care about the result.
Testing debounce and throttle logic without waiting out real timers
A naive test of debounced or throttled code that actually waits out real delays — sleeping for three hundred milliseconds to confirm a debounce eventually fires — works but makes an otherwise-instant test suite slow once enough such tests accumulate, and most modern testing frameworks address this directly with fake timers, which let test code advance simulated time instantly (`jest.advanceTimersByTime(300)`, for instance) rather than genuinely waiting, exercising the exact same debounce or throttle logic without the real-world delay, and this is worth knowing specifically because production debounce and throttle utilities are otherwise a common source of slow, timer-dependent test suites when tested naively.
Trailing invocations that never fire: a debounce with no natural end
A debounce attached to an event that could, in principle, keep firing indefinitely — a mousemove handler during a drag that never ends, for instance — never actually invokes its wrapped function at all for as long as the events keep coming, since every new call keeps resetting the timer before it has a chance to fire, which is correct given debounce's definition but can be a genuine surprise to a developer expecting some periodic feedback during a very long, continuous burst. This is precisely the situation where combining a debounce with a maximum wait time — firing at least once every so often regardless of whether the burst has actually stopped — or reaching for throttle instead, is the better fit, and recognizing which of the two behaviors an interaction actually needs is the recurring judgment call this whole topic comes down to.
requestAnimationFrame as a lightweight, purpose-built alternative
For scroll and resize handlers specifically tied to visual updates, `requestAnimationFrame` is often a cleaner fit than a manually implemented throttle: it schedules a callback to run right before the browser's next repaint, naturally capping the update rate to the display's actual refresh rate without any explicit timing logic to write or maintain, and it automatically pauses entirely when the tab is not visible, which a hand-rolled time-based throttle does not do for free.
Why picking the wrong delay value is its own separate mistake
Beyond choosing between debounce and throttle correctly, the numeric delay chosen for either one is its own independent decision with its own failure modes: too short and the technique barely reduces call frequency at all, defeating the point of adding it in the first place; too long and the interface feels sluggish and unresponsive to the user, who perceives a real, noticeable lag between their action and the visible response — there is no universal correct number, only a value tuned against the specific interaction's own tolerance for delay, discovered by testing rather than assumed from a rule of thumb borrowed from an unrelated use case.
Throttle with a maximum wait: guaranteeing periodic progress
Some throttle implementations accept a maximum-wait option specifically for the trailing-edge case, guaranteeing that even during a continuous, uninterrupted burst of calls, the wrapped function still fires at least once within that bounded interval rather than only at the very start and very end of the burst — a small but meaningful refinement over the simplest possible throttle, and worth knowing to look for by name in whatever utility library is already in use rather than assuming a basic throttle implementation always provides it.
Throttling network requests specifically, versus throttling a handler
Throttling a function that itself makes a network request introduces one further wrinkle beyond throttling a purely local computation: a request already in flight when the next throttle window opens should usually not be duplicated by firing a second, overlapping request for the same underlying data, which is why network-aware throttle implementations often track an in-flight promise directly and reuse it for calls that arrive before the previous request has actually resolved, rather than throttling purely by elapsed time alone.
Composing debounce and throttle together on the same input
Some interactions genuinely benefit from applying both techniques to the same underlying stream of events at once — throttling an autocomplete's visual loading indicator so it updates smoothly throughout typing, while separately debouncing the actual network request so only the final settled query is ever sent — and recognizing that the two techniques operate on different concerns of the same interaction, rather than being mutually exclusive alternatives, opens up compositions neither one alone would achieve.
Throttling versus native browser APIs that already throttle internally
Some browser APIs already throttle their own callback frequency internally — the Intersection Observer API, for instance, batches and limits how often it reports visibility changes — and layering an additional manual throttle on top of an API that already does this is usually redundant complexity rather than an improvement, which is worth checking before assuming every high-frequency event needs the same manual treatment a raw scroll or resize listener does.
Why the very first call in a burst deserves special-case thinking
Whichever variant is chosen, the first event in a burst is the one most likely to represent a genuine, deliberate user action rather than incidental noise — a first keystroke, a first click — and designs that special-case it, responding immediately while suppressing only the rapid repeats that follow, tend to feel more responsive than ones that treat every event in the burst identically regardless of its position.
A short note on naming: why some libraries swap the two terms
A small but genuinely confusing wrinkle across the ecosystem is that not every library uses 'debounce' and 'throttle' with exactly the consistent meanings described here, so checking a specific library's own documented behavior before relying on assumed semantics is worth the extra minute, rather than trusting the name alone to guarantee the trailing-edge-versus-leading-edge, wait-for-silence-versus-bounded-rate behavior actually wanted.