Even if you’ve been doing JavaScript for a while, you might be surprised to learn thatsetTimeout(0) is not reallysetTimeout(0). Instead, it could run 4 milliseconds later:

const start = performance.now()setTimeout(() => {  // Likely 4ms  console.log(performance.now() - start)}, 0)

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 spamsetTimeout, 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!).

One question always vexed me, though: ifsetTimeout was so abused, then why did browsers keep introducing new timers likesetImmediate (RIP), Promises, or even new fanciness likescheduler.postTask()? IfsetTimeout had to be nerfed, then wouldn’t these timers suffer the same fate eventually?

I wrote a long post about JavaScript timersback in 2018, but until recently I didn’t have a good reason to revisit this question. Then I was doing some work onfake-indexeddb, which is a pure-JavaScript implementation of the IndexedDB API, and this question reared its head. As it turns out, IndexedDB wants to auto-committransactions when there’s no outstanding work in the event loop – in other words, after all microtasks have finished, but before any tasks (can I cheekily say “macro-tasks”?) have started.

To accomplish this,fake-indexeddb was usingsetImmediate in Node.js (which shares some similarities with the legacy browser version) andsetTimeout in the browser. In Node,setImmediate is kind of perfect, because it runsafter microtasks but immediately before any other tasks, and without clamping. In the browser, though,setTimeout is pretty sub-optimal:in one benchmark, I was seeing Chrome take 4.8 seconds for something that only took 300 milliseconds in Node (a 16x slowdown!).

Looking out at the timer landscape in 2025, though, it wasn’t obvious what to choose. Some options included:

• setImmediate – only supported in legacy Edge and IE, so that’s a no-go.
• MessageChannel.postMessage – this is the technique used byafterframe.
• window.postMessage – a nice idea, but kind of janky since it might interfere with other scripts on the page using the same API. This approach is used bythesetImmediate polyfill though.
• scheduler.postTask – if you read no further, this was the winner. But let’s explain why!

To compare these options, I wrotea quick benchmark. A few important things about this benchmark:

1. You have to run several iterations ofsetTimeout (and friends) to really suss out the clamping. Technically, per theHTML specification, the 4ms clamping is only supposed to kick in after asetTimeout has been nested (i.e. onesetTimeout calls another) 5 times.
2. I didn’t test every possible combination of 1) battery vs plugged in, 2) monitor refresh rates, 3) background vs foreground tabs, etc., even though I know all of these things can affect the clamping. I have a life, and although it’s fun to don the lab coat and run some experiments, I don’t want to spend my entire Saturday doing that.

In any case, here are the numbers (in milliseconds, median of 101 iterations, on a 2021 16-inch MacBook Pro):

Don’t worry about the precise numbers too much: the point is that Chrome and Firefox clampsetTimeout to 4ms, and the other three options are roughly equivalent. In Safari, interestingly,setTimeout is even more heavily throttled, andMessageChannel.postMessage is a tad slower thanwindow.postMessage (althoughwindow.postMessage is still janky for the reasons listed above).

This experiment answered my immediate question:fake-indexeddb should usescheduler.postTask (which I prefer for its ergonomics) and fall back to eitherMessageChannel.postMessage orwindow.postMessage. (I did experiment with differentpriorities forpostTask, but they all performedalmost identically. Forfake-indexeddb‘s use case, the default priority of'user-visible' seemed most appropriate, and that’s what the benchmark uses.)

None of this answered my original question, though: why exactlydo browsers bother to throttlesetTimeout if web developers can just usescheduler.postTask orMessageChannel instead? I asked my friendTodd Reifsteck, who was co-chair of theWeb Performance Working Group back when a lot of these discussions about“interventions” were underway.

He said that there were effectively two camps: one camp felt that timers needed to be throttled to protect web devs from themselves, whereas the other camp felt that developers should “measure their own silliness,” and that any subtle throttling heuristics would just cause confusion. In short, it was the standard tradeoff in designing performance APIs: “some APIs are quick but come with footguns.”

This jibes with my own intuitions on the topic. Browser interventions are usually put in place because web developers have either used too much of a good thing (e.g.setTimeout), or were blithely unaware of better options (thetouch listener controversy is a good example). In the end, the browser is a “user agent” acting on the user’s behalf, and the W3C’spriority of constituencies makes it clear that end-user needs always trump web developer needs.

That said, web developers oftendo want to do the right thing. (I consider this blog post an attempt in that direction.) We just don’t always have the tools to do it, so instead we grab whatever blunt instrument is nearby and start swinging. Giving us more control over tasks and scheduling could avoid the need to hammer away withsetTimeout and cause a mess that calls for an intervention.

My prediction is thatpostTask/postMessage will remain unthrottled for the time being. Out of Todd’s two “camps,” the very existence of theScheduler API, which offers a whole slew of fine-grained tools for task scheduling, seems to point toward the “pro-control” camp as the one currently steering the ship. Although Todd sees the API more as a compromise between the two groups: yes, it offers a lot of control, but it also aligns with the browser’s actual rendering pipeline rather than random timeouts.

The pessimist in me wonders, though, if the API could still be abused – e.g. by carelessly using theuser-blocking priority everywhere. Perhaps in the future, some enterprising browser vendor will put their foot more firmly on the throttle (so to speak) and discover that it causes websites to be snappier, more responsive, and less battery-draining. If that happens, then we may see another round of interventions. (Maybe we’ll need ascheduler2 API to dig ourselves out of that mess!)

I’m not involved much in web standards anymore and can only speculate. For the time being, I’ll just do what most web devs do: choose whatever API accomplishes my goals today, and hope that browsers don’t change too much in the future. As long as we’re careful and don’t introduce too much “silliness,” I don’t think that’s a lot to ask.

Thanks to Todd Reifsteck for feedback on a draft of this post.

Leave a commentCancel reply

I'm Nolan, a programmer from Seattle working at Socket. All opinions are my own. Photo by Cătălin Mariș.

• Mastodon
• GitHub
• npm