Why do browsers throttle JavaScript timers?

"Nearly a decade ago when I was on the Microsoft Edge team, it was explained to me that browsers did this to avoid "abuse." I.e. there are a lot of websites out there that spam setTimeout, so to avoid draining the user's battery or blocking interactivity, browsers set a special "clamped" minimum of 4ms. This also explains why some browsers would bump the throttling for devices on battery power ( 16ms in the case of legacy Edge), or throttle even more aggressively for background tabs ( 1 second in Chrome!)."

"To accomplish this, fake-indexeddb was using setImmediate in Node.js (which shares some similarities with the legacy browser version) and setTimeout in the browser. In Node, setImmediate is kind of perfect, because it runs after microtasks but immediately before any other tasks, and without clamping. In the browser, though, setTimeout is pretty sub-optimal:"

setTimeout(0) frequently does not run immediately; browsers commonly clamp minimal timer delays (often to about 4ms) to prevent abusive rapid timers that drain battery or block interactivity. Some browsers increase throttling on battery power or for background tabs, producing larger minimum delays. Alternative scheduling mechanisms such as setImmediate, Promises (microtasks), and scheduler.postTask exist and behave differently in the event loop. IndexedDB requires auto-commit after microtasks complete but before the next task begins, so Node's setImmediate fits that window well, while browser setTimeout is suboptimal due to clamping and throttling.

Read at Read the Tea Leaves