Debounce vs Throttle in JavaScript: Which One Should You Use for Search Inputs?

HighIntermediateJavascript

By FrontendAtlas Team · Updated Jan 30, 2026

Quick Answer

Debounce and throttle are two core JavaScript performance optimization techniques for controlling how often a function runs in response to frequent events like typing, scrolling, or resizing. A very common frontend interview question is designing a live search input: should you debounce or throttle the API call, and is 200ms a good debounce value?

Answer

The real interview problem

This question is not about definitions. It's about this:

"How do you prevent expensive work from running too often when the user types?"

Typing in a search input can easily trigger 10–20 events per second. Calling an API on each keystroke is wasteful, slow, and can even get you rate-limited.

Debounce vs Throttle — the mental model

Technique	Mental model	What it does
Debounce	"Wait until the user stops typing"	Runs the function only after no events happened for N ms
Throttle	"Run at most once every N ms"	Runs the function at a fixed maximum rate

Both reduce frequency, but they solve different UX problems.

Which one should you use for search?

Almost always: Debounce.

Why?

You only care about the final query

Intermediate keystrokes produce useless requests

Debounce waits until the user pauses, then sends one clean request

Is 200ms a good debounce value?

Usually yes — as a starting point.

Common range: 150–300ms

200ms often feels instant to humans

But still cuts request volume massively

Trade-off:

Too small → still spams API

Too big → UI feels laggy

Senior answer: "We should measure and tune this based on UX and backend cost."

Simple debounce implementation

JAVASCRIPT

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

const onSearch = debounce((query) => {
  fetch(`/api/search?q=${query}`);
}, 200);

The real-world bug: race conditions

Even with debounce, this can happen:

1) User searches "rea"
2) Then quickly searches "react"
3) The "rea" request returns after the "react" request
4) UI shows wrong results

Solution:

Cancel in-flight requests (AbortController)

Or track request IDs and ignore stale responses

When should you use throttle instead?

Throttle is better for continuous signals:

Scroll handlers

Resize events

Mouse move / drag

Analytics sampling

In those cases you want regular updates, not just the final value.

Common mistakes

Using throttle for search → sends half-baked queries

Debouncing too aggressively → UI feels broken

Not cancelling previous requests

Letting stale responses overwrite fresh ones

One-sentence interview answer

"For search inputs I would use debounce, not throttle, because I only care about the final query — and ~200ms is a good starting point that should be tuned based on UX and backend cost, plus I’d handle request cancellation to avoid race conditions."