Interval choice trades felt responsiveness for request volume
Aliases: debounce wait · throttle interval · maxWait · settle time
What it is
The same “run after idle” or “sample at a rate” strategy can differ by an order of magnitude in how fast it feels and how many requests it produces, depending on the number chosen for the wait or the interval. Parameter choice is that number: it moves two things at once — how long after a pause the result appears, and how much derived work a burst triggers. The right strategy with the wrong number is still slow and noisy.
This is not a restatement of what each strategy does. It is about the knobs: wait, interval, and whether work is forced to fire before some ceiling.
Why it happens
A trailing wait is stacked after the last input. The hands have already stopped; the interface still sits through one extra wait, then the network. Too short a wait, and ordinary gaps inside a word also fire, so request volume collapses back toward one-per-key and the strategy did no work. Too long, and the sentence is finished in the head while on-screen suggestions sit still — the lag lives in the empty wait, not in the algorithm. A throttle interval that is too tight fills the main thread and the API with a plateau instead of a spike. One that is too sparse makes values jump between samples; people read that as jank, not as savings.
Two other knobs are easy to miss. Leading versus trailing: firing on the first beat saves felt response, but spends one request on an incomplete first mouthful. A maximum wait: some people type for seconds without a pause; without a ceiling, trailing work never lands; with one, even a dense stream flushes on a schedule, at the cost of running on mid-burst values.
Where it stops holding
The number does not travel across tasks. Search suggestions, relayout after resize, and scroll-position reporting have different acceptable empty waits; a wait that feels right on search turns a drag preview into chunks. Slow typists and assistive character-by-character input have longer within-word gaps; a short wait splits one word into many queries, so the parameter must stretch or give way to “run on blur / confirm”. When a request is billed or has write side effects, the cost of a tight interval is money and duplicate writes, not just jank — shortening for feel is the wrong ledger. Values tuned on the team’s own touch-typing traces do not match real pause distributions.
Applying it
- For each kind of derived work, record two quantities: delay from pause to first visible result, and how many requests or recomputes a typical burst fires. Read them together.
- Tune on real input traces, not a millisecond number copied from elsewhere. Add a maximum wait when continuous input would otherwise never land.
- Keep local immediate feedback out of these parameters: characters must appear at once; the knobs constrain requests and relayout only.
- How to check: run three traces — fast typing, slow typing, pause-then-continue. On the fast path, requests should be well below key count, and the post-pause result should appear inside an acceptable empty wait. Lengthen the wait until suggestions are obviously late; shrink it toward zero until requests approach key count. Both ends must be reproducible, or the parameter is not actually doing the work.