JavaScript Debounce vs Throttle: 8 Real Code Differences Explained

Type a search box fast and watch your browser tab quietly slow down. Ever wondered why? You just triggered an event handler dozens of times in one second, and one of two techniques, debounce or throttle, is almost certainly the fix your code needs right now.

A keystroke, a scroll, a window resize. Each one can fire an event handler dozens or hundreds of times a second, and most of the time your code does not need to react to every single one of them.

Debounce waits for a pause. It delays running your function until the events stop coming for a set amount of time, then runs it once. Throttle takes the opposite approach. It lets your function run right away, then blocks any further calls until a fixed amount of time has passed, guaranteeing a steady drip instead of a single delayed burst.

That single distinction, wait for silence versus run on a schedule, is the entire javascript debounce vs throttle decision. Everything else in this guide is just showing that difference in real, running code.

Chrome DevTools makes the underlying problem easy to see for yourself. Open the Performance panel, record a fast typing session or a scroll on an unoptimized page, and the flame chart fills with dozens of tiny, overlapping tasks that a debounce or throttle wrapper would collapse into a handful.

Once you have watched both techniques fire in real code, the javascript debounce vs throttle distinction stops being two vocabulary words and starts being an actual design decision you make on purpose, handler by handler.

A debounce function is smaller than most people expect. It wraps your original function, and every new call cancels whatever timer was already waiting, then starts a fresh one.

function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

Only one thing ever happens on every call: the old timer gets thrown away and a new one takes its place. As long as new calls keep arriving before that timer finishes, the wrapped function never actually runs.

Reading the code above explains the theory. Running it against a simulated burst of keystrokes, five calls fired 80 milliseconds apart wrapped in a 300 millisecond debounce, shows exactly which calls survive and which ones get cancelled.

This is the moment where javascript debounce vs throttle stops being a diagram and turns into five real console lines you can read from top to bottom.

const debouncedSearch = debounce((query) => {
  console.log(`FIRED search("${query}")`);
}, 300);

['r', 're', 'rea', 'reac', 'react'].forEach((query, i) => {
  setTimeout(() => debouncedSearch(query), i * 80);
});

Actual output from the debounce demo above. Five keystrokes went in, exactly one search call came out.

Throttle looks similar on the surface, a wrapper function holding some state in a closure, but the logic inside runs the opposite way around. The first call goes through immediately, and a cooldown flag blocks every call that follows until the limit expires.

function throttle(fn, limit) {
  let inCooldown = false;
  return function (...args) {
    if (inCooldown) return;
    fn.apply(this, args);
    inCooldown = true;
    setTimeout(() => (inCooldown = false), limit);
  };
}

Notice what is missing compared to debounce. There is no clearTimeout() here at all, since throttle never cancels anything. It only ever ignores calls while the cooldown flag is still set.

Both wrappers rely on the same underlying mechanism to delay work, the macrotask queue described in the WHATWG HTML timer specification, where every setTimeout() callback waits its turn behind whatever else is already scheduled.

The same test structure, eight simulated scroll events fired roughly every 60 milliseconds, this time wrapped in a 200 millisecond throttle, shows a completely different pattern of survivors.

const throttledScroll = throttle((pos) => {
  console.log(`FIRED updateStickyHeader(scrollY=${pos})`);
}, 200);

[40, 90, 150, 210, 260, 320, 400, 470].forEach((pos, i) => {
  setTimeout(() => throttledScroll(pos), i * 60);
});

Actual output from the throttle demo above. Eight scroll events went in, calls came out on a steady schedule instead of all at once.

The two demos side by side make the javascript debounce vs throttle behavior almost impossible to confuse again, since the real timestamps do the explaining instead of a description of what should happen. This exact pattern, wrapping a function to control its own call frequency, is common enough that CSS-Tricks has a widely referenced writeup comparing several variations side by side.

The javascript debounce vs throttle choice usually falls out naturally once you ask a simple question about the handler in front of you. Does the user care about the very last state, or does the user care about a steady stream of updates the whole time an action is happening? Making the right javascript debounce vs throttle call up front avoids retrofitting the other pattern into a handler later.

An unthrottled scroll handler is a classic way to quietly wreck a page's Interaction to Next Paint score, since every single scroll event competes with the browser for main thread time.

The same problem shows up as inflated Total Blocking Time during a Lighthouse audit, where long, uninterrupted JavaScript tasks push the main thread past the point where it can respond to input quickly.

A feature like the scroll based heading highlighter in automatically highlighting the current heading while scrolling, or the position tracking behind a sticky table of contents built with CSS and JavaScript, both depend on a scroll listener that runs constantly, which makes them a textbook case for throttle rather than debounce.

Google's own guidance on Interaction to Next Paint specifically calls out unthrottled scroll and input handlers as one of the most common causes of a slow score, which lines up exactly with what the real timestamps earlier in this guide showed. Every javascript debounce vs throttle decision made in a real codebase eventually shows up in a Core Web Vitals report, for better or worse.

A hand rolled debounce or throttle function is short enough to get subtly wrong, and most of the javascript debounce vs throttle bugs that reach production trace back to the same handful of mistakes.

• Creating a new debounced function on every render: in a framework like React, defining the wrapped function inside a component body resets its internal timer state constantly. Create it once, outside the render path.
• Forgetting to remove the event listener on cleanup: a debounced or throttled handler still attached to a removed element keeps a timer alive and can fire against state that no longer exists.
• Using debounce where users expect immediate feedback: a button that visibly does nothing for 300 milliseconds reads as broken, not careful. Throttle, or a short debounce under 100 milliseconds, usually feels better here.
• Never testing the actual timing: logging real timestamps, the same way the two demos above did, catches an off by one delay value long before a user does.
• Reaching for a library before trying the plain version: both functions are well under fifteen lines. Understanding the two above makes reading MDN's addEventListener reference and any library's implementation far easier later.