Why Debounce and Throttle Matter in UIs

Certain DOM events fire at extremely high rates. The keypress event fires on every keystroke. The scroll event fires dozens of times per second while scrolling. The resize event fires continuously while the user drags the window border. Processing every event individually can overwhelm both the browser and your server.

If your keypress handler makes an API call on every keystroke, a user typing "React hooks" (11 characters) triggers 11 network requests, most of which are for incomplete queries. Similarly, updating a parallax animation on every scroll pixel fires hundreds of React re-renders per second. This wastes CPU, network, and battery.

Debounce delays execution until the event has stopped firing for a specified period. If the user is still typing, the timer resets on each keystroke. Only after N milliseconds of silence does the handler finally execute once. Debounce answers: "run this after the user finishes doing something."

Throttle limits execution to at most once per time interval, regardless of how many events fire. If the user scrolls rapidly, a 100ms throttle ensures your handler runs no more than 10 times per second. Throttle answers: "run this regularly but not more often than N ms."

Debounce is the right choice when you only care about the final value after the user stops. Classic cases: search input (send API request after typing pauses), window resize handler (recalculate layout after resize ends), and form field validation that checks a server (wait for full input before validating).

Throttle is the right choice when you want regular updates during continuous activity. Classic cases: scroll position handler (update a read-progress bar or sticky header at max 30fps), mouse move tracking (record cursor position for analytics), and drag event handlers (update a draggable element position smoothly without flooding).

Writing a debounce or throttle from scratch without full understanding leads to bugs like missing the final event (trailing edge), firing on wrong edges, or not cleaning up timers on component unmount. It is generally better to use battle-tested implementations from libraries like lodash, which handle all edge cases correctly.

Lodash provides _.debounce(fn, wait) and _.throttle(fn, wait) with options for leading and trailing edge behavior. The returned function has a .cancel() method to abort a pending invocation and a .flush() method to execute it immediately. These should be wrapped in useRef in React to avoid recreation on re-render.

Even 50 extra React re-renders per second from an unthrottled scroll handler can consume significant CPU, particularly on low-end mobile devices. A 16ms frame budget (60fps) means each re-render must complete in under 16 milliseconds to avoid dropped frames. Debounce and throttle are your first line of defense against frame-rate issues.

Not all high-frequency handlers need debouncing. If the event handler just reads a value without updating state or calling APIs — for example, recording the last mouse position in a ref — no debounce is needed. Only debounce or throttle handlers that trigger expensive operations: state updates, API calls, or DOM measurements.

When a component unmounts, any pending debounced call should be cancelled to prevent a state update after unmount. If you use a useRef to store the debounced function, call debouncedFn.cancel() in the useEffect cleanup. Lodash debounced functions expose this method for exactly this purpose.

Which technique should you use to fire an API call when the user stops typing in a search field?

High-frequency events like keypress, scroll, and resize can cause performance issues if handlers run on every event. Debounce waits for silence and is best for search inputs and resize handlers. Throttle limits frequency and is best for scroll and drag. Use lodash implementations stored in refs, and always cancel on component unmount.