Debounce vs Throttle in JavaScript: How They Work, When to Use Each, Tested

A search box calls an API on every keystroke. Typing “pen stand” sends nine requests, eight of which are useless, and the results may even arrive out of order. A scroll handler recalculates layout sixty times a second and the page stutters. Debounce and throttle are the two standard fixes, and choosing the wrong one creates its own bugs.

We wrote small implementations of both and fed them simulated events in Node.js 24, recording when each function actually ran. Timer precision varies by system, so your milliseconds will differ slightly, but the pattern will not.

The short answer

Why limit events at all?

Browsers fire input events on every keystroke, and scroll, mousemove and resize events many times per second. If each handler does real work, such as an API call, a heavy calculation or a layout read, the page wastes battery, floods the server and feels slow. Limiting how often the handler runs keeps the interface smooth and the backend calm. On the server side, the equivalent protection is API rate limiting.

How debounce works

function debounce(fn, wait) {
  let t;
  return (...args) => {
    clearTimeout(t);
    t = setTimeout(() => fn(...args), wait);
  };
}

Every call cancels the previous timer and starts a new one. The function only runs when a full wait period passes with no new calls. The variable t survives between calls because of a closure, which is what makes this short implementation work.

Debounce test: a search box

We simulated typing “pen stand” as 8 keystrokes, 80 ms apart, with a 300 ms debounce:

const search = debounce((q) => calls.push(`search("${q}")`), 300);
for (const q of ["p","pe","pen","pen ","pen s","pen st","pen sta","pen stand"]) {
  search(q);
  await sleep(80);
}

// debounce: 8 keystrokes 80ms apart -> 1 call(s) [ ' 904ms search("pen stand")' ]

One search ran, with the complete text, about 300 ms after the last keystroke. Without debouncing, there would have been eight requests. A good wait for typing is usually 200 to 500 ms: short enough to feel instant, long enough to skip most intermediate keystrokes.

When debounce never fires

Debounce has a sharp edge. We called a 300 ms debounced function every 100 ms for 1.5 seconds:

debounce during 1.5s of constant input: fired 0 times
after input stops: fired 1

As long as events keep arriving faster than the wait, the timer keeps resetting and the function never runs. For a search box that is fine. For a live progress display or an auto-save during a long typing session, it is a bug: nothing is saved until the user pauses. Lodash’s debounce offers a maxWait option for exactly this, forcing a call at least every so often.

How throttle works

function throttle(fn, wait) {
  let last = -Infinity;
  return (...args) => {
    const now = Date.now();
    if (now - last >= wait) {
      last = now;
      fn(...args);
    }
  };
}

The first call runs immediately. Calls during the next wait milliseconds are ignored. After that, the next call runs, and so on. The function runs at a steady maximum rate for as long as events keep coming.

Throttle test: scrolling

We simulated scrolling from position 0 to 1000 in steps of 20, about every 16 ms, which is 51 events, with a 200 ms throttle:

throttle (leading only): 51 events -> 5 calls [ 0, 240, 460, 660, 860 ]

Instead of 51 updates, the handler ran 5 times, spread evenly through the scroll. But look at the last value: 860. The scroll ended at 1000, and that final position was never handled. For something like a “back to top” button that should appear at the bottom of the page, this is a real bug.

Leading and trailing calls

The fix is a trailing call: if events were ignored during the last interval, run once more at the end with the latest arguments. We tested a version with both leading and trailing calls on the same scroll:

throttle (leading+trailing): -> 7 calls, last value 1000

Now the final position, 1000, was handled. The same idea applies to debounce in reverse: a leading debounce runs on the first event and then ignores the burst, which suits buttons that should react instantly but must not be double-clicked.

Which to use where

• Search suggestions, filtering a list: debounce, 200 to 400 ms.
• Form field validation: debounce, so errors do not flash while the user is still typing.
• Auto-save: debounce with a maximum wait, so long sessions still save.
• Window resize recalculation: debounce if you only need the final size, throttle if the layout must follow along.
• Infinite scroll, scroll-spy, sticky headers: throttle with a trailing call.
• Mouse move, drag, game input: throttle, or requestAnimationFrame for visual updates.
• Analytics events: throttle, to cap the volume sent.

Libraries and frameworks

Our implementations are minimal teaching versions. Production code needs cancellation, flushing, correct this handling and edge cases around timers. Lodash’s debounce and throttle are the common choice and support leading, trailing and maxWait options, plus cancel() and flush() methods.

In React, create the debounced function once, for example with useMemo or useRef, rather than on every render. A new debounced function per render has its own new timer, so nothing is ever debounced. Cancel pending calls when the component unmounts, or a late call may update state that no longer exists.

requestAnimationFrame for visual updates

For work that only changes what is drawn, such as moving an element with the mouse, browsers offer a better throttle: requestAnimationFrame. It runs your code right before the next screen repaint, usually 60 times a second, and pauses in background tabs. Store the latest event data, and schedule at most one frame callback at a time. Use time-based throttling for things that are not about drawing, such as network calls.

Testing timing code

Real timers make tests slow and flaky. Our demo took several seconds because it really waited. In a test suite, use fake timers instead: Jest and Vitest both provide them, letting a test call the debounced function, advance the clock by 299 ms and assert nothing happened, then advance 1 ms more and assert one call. Test the edge cases: a single call, a burst, a continuous stream longer than the wait, and cancellation. Those are exactly where our measurements showed surprising behaviour.

Final thoughts

Debounce waits for quiet; throttle keeps a steady pace. Use debounce when only the final value matters, such as a search term, and throttle when the user needs continuous feedback, such as scrolling. Add a trailing call to throttle so the last event is never lost, add a maximum wait to debounce for long sessions, and prefer a well-tested library in production.

Frequently asked questions

Keep learning