2.0-alpha Menu

debounceTime vs throttleTime

If your stream is created from key presses or mouse movements, you’ll likely deal with bursts of events. But you can’t react to every single event, as it would overload the CPU or flood the servers with too many requests.

❚ debounceTime rate-limits events, based on an “emission silence” window of time. ❚ throttleTime doesn’t delay events.

They both accept a time period argument, such as 500 milliseconds.


This is how ❚ debounceTime operates:

  • Whenever an event is emitted, the period of silence measured restarts from zero
  • The card waits for a “due time” silence and then emits the latest value of the input stream
  • As a result, it returns a new stream of debounced events


This is how ❚ throttleTime operates:

  • It starts by emitting the first event of the input stream
  • Then, it limits the rate of events to at most one per time period
  • As a result, it returns a new stream of “throttled” events

See also

debounceTime vs delay

scan vs reduce

zip vs combineLatest

The JavaScript pipeline operator proposal

💌 I create something new each week!
Learn Reactive Programming and stay tuned.

Occasional updates, plus:

Cédric Soulas - Freelance Developer Advocate. Learn more.

Follow 👨‍💻 Hire me