I4.01.1debounce until idledesign

Debounce waits until input has stopped before running

Aliases: debounce · wait for idle · trailing debounce · settle then run

What it is

Twelve keystrokes in a search field should not become twelve queries. Debounce postpones work until the input stream has gone quiet: each new event resets the timer, and only after the idle gap lasts the chosen wait does the function run, once, on the last value. The question it answers is “has this burst finished”, not “how often should we sample while it continues”.

It belongs on search-as-you-type, typeahead, layout that should wait until a resize settles, address lookup. A single click or a single submit is not a burst; it does not need this layer.

Why it happens

Keystrokes arrive in bursts, not as a smooth Poisson process: tens to a couple of hundred milliseconds between letters, longer gaps between words or while planning. Debounce treats “a gap longer than the wait” as evidence that a burst ended. The cost is that after the real pause, the user still sits through one extra wait before seeing a result computed from the finished string. The wait is a bet that the next key will not arrive immediately — win it, and a pile of intermediate work is skipped; lose it, and search feels late.

Only the last value matters because the intermediates are usually meaningless for these tasks: “interacti” is not the query, “interaction” is. Local surface changes (inserted character, caret) must still happen immediately. Debounce binds only to derived work: requests, relayout, suggestions. Debouncing the paint of the key itself makes typing feel like hitting air.

Where it stops holding

A continuous stream has no “stopped” event: scroll, drag, and tracking-style drawing go dark in the middle if work waits for idle. IME composition is not idle while candidates are still moving; debouncing pinyin fragments fires half-finished strings. Slow typists, switch scanning, and chopped speech have a different pause structure than touch-typing; a short fixed wait treats a within-word hesitation as the end of the burst. When every event has unmergeable meaning (stepwise undo, stepwise recording), debounce swallows steps that must remain.

Applying it

  • Attach debounce to derived work that only cares about the finished string — search, filters, suggestions, relayout — not to key painting, pressed state, or character insertion.
  • Prefer trailing: run once on the final value after idle. If the first instant must feel alive, add local immediate feedback; do not fire the request on the first event.
  • For IMEs: enter debounce after commit (the character hits the field), not on composition updates.
  • How to check: type a whole word quickly. Network or recomputation should happen once after the pause, not once per letter. An implementation that also delays local typing fails. Compose a word with an IME and confirm pinyin fragments are not queried before commit.

Related

  • Same group: I4.01.2 Throttle runs at a fixed rate while input continues · I4.01.3 Interval choice trades felt responsiveness for request volume
  • Nearby: I1.04 Input latency and tracking · I4.09 Tempo and interaction rhythm
  • Search terms: debounce · trailing edge · search as you type

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I4.01.1