Throttle runs at a fixed rate while input continues
Aliases: throttle · rate cap · leading throttle · sample while moving
What it is
Scroll, drag and pointer-move can dump dozens to hundreds of events in a second. The motion is the task; waiting for it to stop would go dark in the middle. Throttle caps how often work may run: while events keep arriving, it fires at most once per interval, using the sample of that slot. The process stays updated, and the work stays inside a budgeted rate.
This is not “run once after idle”. Throttle wants regular samples during motion, not a single appearance at the end.
Why it happens
Continuous input has no trustworthy end marker. A scroll may last seconds; a finger may stay down on a slider. Binding work to every native event fills the main thread and the network with the device’s event machine; frame time is eaten by the handler, and tracking gets worse. Throttle rewrites the stream as a metronome: one slot, one run. A common leading form fires on the first beat so the first frame of motion already has a position; later events wait for the next slot. Trailing makes sure the last position on release is landed, so the view does not freeze on a mid-slot sample.
What throttle keeps is a time-uniform sample, not the full event set. For scroll offset, window width, drag coordinates, uniform samples are enough. For a string where every character must be handled, uniform samples drop letters in between.
Where it stops holding
When meaning lives in the finished burst rather than the path (search a complete word, validate a complete email), throttle keeps running on half-built values — wasteful and wrong. Repeated clicks on a submit control should not be swallowed by a rate cap; disable the control or make stepping explicit, or people cannot tell which press counted. Tracking drawing and instrument-like control need samples near frame rate; an interval visibly longer than a frame turns the path into stairs. On battery and background tabs a fixed rate may still be too high; align with page visibility and the device refresh, rather than a frozen millisecond number.
Applying it
- Use on scroll listeners, drag previews, live resize previews, pointer-move sampling. Do not use on “search once after idle” or “submit once”.
- If the path must track the hand, choose leading so the first beat has a position. If the final value on release must land, add trailing for that last run.
- Align the interval with display refresh or with a request rate the product can afford, not with how dense native events are.
- How to check: hold a scroll for several seconds. Handler count should sit near “seconds × rate”, not near the native event count. The position after release must be correct. Wiring the same rate limiter to a search field is a counterexample: every beat queries a half-typed word.