Why do browsers throttle JavaScript timers?

15 vidyesh 9 9/12/2025, 5:35:08 PM nolanlawson.com ↗

Comments (9)

timhh · 4m ago
I asked about this a few years ago on SO and there is some good info: https://stackoverflow.com/q/61338780/265521

E.g. Chrome has this comment:

  // Chromium uses a minimum timer interval of 4ms. We'd like to go
  // lower; however, there are poorly coded websites out there which do
  // create CPU-spinning loops.  Using 4ms prevents the CPU from
  // spinning too busily and provides a balance between CPU spinning and
  // the smallest possible interval timer.
At the time at least the 4ms only kicks in after 5 levels of nesting, as mentioned in the article, but there was still a 1ms limit before that.

Seems like it has been removed though based on jayflux's comment.

BugsJustFindMe · 46m ago
Because browser developers still have major incentive to care about not misusing the resources (cpu/battery) of browser users, and website developers very clearly do not.
cosmic_cheese · 9m ago
This the natural consequence of a platform having high capability but low barrier to entry. Conscientious use of resources cannot be assumed and is in fact the exception rather than the rule, and so guardrails must be put in place.
nielsbot · 7m ago
I remember reading that high precision timers can be used for browser fingerprinting and/or for timing attacks, but I didn't anything specifically about setTimeout()/setInterval() after searching a bit.

Also--loosening the accuracy of timers allows the system to optimize CPU power states and save battery. Again, not sure if that's related here.

Maybe someone else here can add more detail.

jagged-chisel · 24m ago
Have I not always heard that timeout-based callbacks always run at or after the timeout, but never before?

“Do this {} at least Xms from now”, right?

jayflux · 27m ago
> Even if you’ve been doing JavaScript for a while, you might be surprised to learn that setTimeout(0) is not really setTimeout(0). Instead, it could run 4 milliseconds later:

Is this still the case? Even with this change? https://chromestatus.com/feature/4889002157015040

timhh · 3m ago
I think that change is talking about the minimum timeout for the first 5 nested calls to `setTimeout(0)`.

Previously the first 5 would take 1ms, and then the rest would take 4ms. After that change the first 5 take 0ms and the rest take 4ms.

swsieber · 18m ago
I think it's still the case. The 4ms happens if you call setTimeout nested several times. I don't know the exact limit. But it's 5-ish times where that kicks in IIRC.

Edit: Here's the MDN bit on that, I was correct:

https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...

> browsers will enforce a minimum timeout of 4 milliseconds once a nested call to setTimeout has been scheduled 5 times.

And the link from there to the spec about that:

https://html.spec.whatwg.org/multipage/timers-and-user-promp...

> If nesting level is greater than 5, and timeout is less than 4, then set timeout to 4.

BinaryIgor · 1h ago
The story of web development:

"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."