Glossary / Throttling
Throttling
Throttling limits how often a function can run during a continuous stream of calls. A common policy runs at most once per interval, optionally preserving the latest call at the end. It is useful for scroll/resize telemetry, pointer movement, and rate-limited UI work where periodic updates matter while activity continues.
Scheduling policies
A leading throttle invokes immediately then suppresses calls until the interval passes. A trailing throttle schedules the latest suppressed call at the end. Some implementations combine both. A timer-based throttle can drift under load; a timestamp-based policy and a frame-based policy have different semantics. For visual work, requestAnimationFrame often gives better alignment with painting than an arbitrary timer.
Throttling does not make an expensive handler cheap; it only reduces frequency. It does not automatically cancel async work, prevent overlapping requests, or guarantee a maximum network rate if retries and other callers exist. Define lifecycle cleanup and whether the latest value or first value in each window is retained. For APIs, server-side rate limiting remains necessary; client throttling is a UX optimization, not an abuse control.
Interview questions
- What does throttle guarantee? A bound on invocation frequency under its chosen policy.
- How differs from debounce? Throttle runs periodically during a burst; debounce waits for the burst to stop.
- Should scroll rendering use setInterval? Often use rAF to align work to frames.
- Does client throttle enforce API protection? No; enforce limits server-side too.