If a search box, scroll handler, or resize listener fires too often and lags the page, you need either debounce or throttle. They sound similar and are constantly confused. This article gives you a clear mental model, a real example, and a rule you can apply in seconds so you pick the right one every time.
The core difference
Both techniques limit how often a function runs in response to rapid events. They differ in when they let the function run.
- Debounce waits until the events stop. It runs the function once, after a quiet period. Every new event resets the timer.
- Throttle runs the function at a steady maximum rate. No matter how many events fire, it runs at most once per interval.
A short way to remember it: debounce answers “tell me when the user is done,” throttle answers “tell me at a regular pace while it keeps happening.”
When to use debounce
Use debounce when you only care about the final state after activity settles.
- A search box that queries an API after the user stops typing.
- Auto-saving a form once edits pause.
- Validating input after the user finishes, not on every keystroke.
- Reacting to a window resize once it ends.
When to use throttle
Use throttle when you need steady updates during a continuous action.
- Scroll position tracking for a progress bar or sticky header.
- Mouse move handlers for drag or drawing.
- Firing analytics at a controlled rate during continuous movement.
- Infinite scroll checks that must run periodically while scrolling.
A real scenario: the search box
Imagine an autocomplete field. A user types “keyboard” — eight characters, eight keystrokes. Without any control, you fire eight API requests, and the results from an early letter may arrive after a later one, showing stale suggestions.
With a 300 ms debounce, the function waits until typing pauses. The user types the full word, stops, and one request fires. You cut eight requests to one, avoid race conditions, and reduce server load.
Now compare that to a scroll progress bar. If you debounced scroll, the bar would only update after the user stops scrolling, which feels broken. Here you throttle to, say, every 100 ms so the bar updates smoothly while scrolling continues. Same problem shape, opposite solution.
Debounce vs throttle at a glance
| Question | Debounce | Throttle |
| Runs when? | After events stop | At a fixed interval |
| Good for | Final result | Ongoing updates |
| Search input | Yes | No |
| Scroll progress | No | Yes |
| Guaranteed to run during activity? | No | Yes |
Common mistakes and how to fix them
- Debouncing scroll or drag. The UI feels frozen until the action stops. Fix: throttle continuous visual updates instead.
- Recreating the debounced function on every render. In component frameworks, defining it inside the render body creates a new timer each time, so it never debounces. Fix: create it once and keep a stable reference.
- Forgetting the trailing or leading edge. Some implementations run at the start of the interval, others at the end. If your handler feels one step behind, check whether you need the leading or trailing call. Fix: pick a library option that matches, or handle both edges deliberately.
- Delays that are too long. A 1000 ms debounce on search feels sluggish. Fix: 200 to 400 ms is a common comfortable range for typing.
- Not cleaning up timers. Leftover timers can fire after a component unmounts. Fix: clear the timer on cleanup.
Action steps
- Ask: do I need the final value, or steady updates during activity?
- Final value only, choose debounce. Steady updates, choose throttle.
- Pick a delay: 200 to 400 ms for typing, 60 to 150 ms for scroll or move.
- Create the wrapped function once with a stable reference.
- Add cleanup so pending timers cannot fire after teardown.
Conclusion and next step
Debounce waits for quiet, throttle keeps a steady beat. Match the technique to whether you want the ending state or ongoing feedback. Next step: find one noisy event handler in your project, decide which pattern fits, and apply it today.
FAQ
Can I use both together?
Yes, in different places. A page might throttle scroll for a progress bar and debounce a search field at the same time. They solve different problems.
Which is better for performance?
Neither is universally better. Throttle guarantees periodic execution, debounce may skip everything until activity ends. The right choice depends on the behavior you need, not raw speed.
Do I need a library like Lodash?
No. Both can be written in a few lines. Libraries such as Lodash are convenient and well tested, with options for leading and trailing edges, but they are not required.
What delay should I start with for search?
Around 300 ms is a common starting point. Test with real typing speed and adjust so it feels responsive without firing on every keystroke.
References
- MDN Web Docs: guidance on event handling and timers such as
setTimeout. - Lodash documentation: the
debounceandthrottlefunctions and their options.