Why do browsers throttle JavaScript timers?
(nolanlawson.com)54 points by vidyesh 8 hours ago
54 points by vidyesh 8 hours 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.
This is an enormous problem with software in general. IMO it's probably because software has been abstracted into the stratosphere to the point that most developers aren't at all aware of resources or even the machine it's running on. That's someone else's problem. I really hate it.
Whenever I refactor and endpoint that takes the p99 from 1 minute to 1 second, I think about how a 4k video being uploaded undoes all of that progress
Since the result is the same to the end user regardless of what I say here, I know I will not sway many people but...
As someone who has done what I will call "corporate web dev" for a long time, it's almost never the actual site or web app that is abusing your resources. It's all the junk 3rd-party scripts that the business and marketing people force onto it.
These scripts are intended to be "low code" solutions. Even if the developers working at those places mean well, nobody reads their docs least of which the marketing goons with unfettered access via a CSP nonce copy-pasting whatever example <script> tags they think they need to inject to make the thing go.
If you ever want a laugh and have tons of free time you should find one of those sites loaded with these kinds of scripts that an ad blocker would normally get rid of, read the docs for how those scripts were supposed to be used, and bask in the insane stupidity and cargo cult nonsense causing duplicate events and many redundant http calls and websockets... and then turn your ad blocker back on.
You may then ask yourself sensible questions such as: "doesn't all this royally fuck up their analytics data?" and "does some poor soul making reports from that mess ever clean it up?". The answer is yes it does, and no they don't. They instead will try to play the blame game and claim it's the underlying site or web app causing the issues until they find another job. There's a lot of churn in that space.
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.
Seems like it has been removed though based on jayflux's comment.
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.
You might be referring to the Spectre mitigation changes:
Timer precision from performance.now and other sources is reduced to 1ms (r226495)
https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
Although you can claw that precision back by enabling cross-origin isolation for your site, at least in Firefox and Chrome, which both quantize high res timers to 100μs in non-isolated contexts but only 5μs in isolated contexts. I'm not sure exactly what Safari does.
That's high precision clocks (aka Preformance.now(), with sub-millisecond resolution) not timers.
The precision of setTimeout has never been high, it kind-of maps to the OS scheduler and the OS scheduler often enforce their own minimum timeouts (Windows has defaulted to 15.625 ms resolution for a very long time, and the newer high resolution timers max out at 1ms across most operating systems)
As someone who wrote an entire indexedDB wrapper library just to understand the "micro task" issues that are referenced in this blog post, and THEN dedicated a couple hundred words of my readme to explaining this footgun[0], I am so glad to hear about `scheduler.postTask`. That's new information to me!
Thanks for including that example!
[0] https://github.com/catapart/record-setter?tab=readme-ov-file...
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."
Challenge accepted.
https://developer.mozilla.org/en-US/docs/Glossary/blink_elem...
I guess it's the end of days, if tags have stopped blinking.
> And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days. — from The Book of Mozilla, 12:10
This was news to me but incredibly interesting: https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/p...
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?
I don’t think “artificially increased” is correct. See your sibling. If the runtime waits until expiry, and only then adds the task to the end of the work queue, there’s no point at which any delayed work could happen at expiry except the work to place it on the end of (an empty) queue.
Any busy runtime (e.g. one with lots of parallel tasks, plus anything running less than optimally) will have a delay.
Artificially increased is what's happening when you request a timeout of 0 and the browser always makes it 4 ms or more.
Imagine this code:
let value = 0;
(function tick () {
value += 1;
console.log(value);
setTimeout(tick, 1);
})();
this has always been my understanding as well - it schedules a function to run at time, but it won't pre-empt something that is blocking when it needs to run so there's always the possibility that it has to wait for another function to finish before it can run - a timeout is not a guarantee.
Yeah, exactly. Timeout based callbacks register a timer with the runtime, and when the timer is up, then the callback gets added to the end of the task queue (so once the timeout is up, you've got to wait for the current loop iteration to finish executing before your callback gets executed).
I always kinda figured that any "timer" in any language would technically need to work that way unless you're running a very fancy real-time system because multitasking, especially in high load scenarios, means there just may not be clock cycles available for your task at the exact millisecond you set something to execute at.
So it is with JS; I kinda figured EVERYTHING would need to be heavily throttled in a browser in order to respect the device running that browser.
> 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
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.
I was aware of that for browsers; is this also true for Electron?
Electron is just a packager for Chromium, with the minimum code necessary to achieve that objective.
Technically it is a browser. Unless I am making a serious logic flaw here, it should be applicable.
Background javascript processes can really seem to add up across a lot of browser tabs firing up to stay "smart" or "current" like they're the only tab in existence in their user's life.
I'm not sure if many people struggle with browser tabs gone wild. Limiting Javascript can have varying degrees of success since it's relative to how the page/site/app is built to begin with.
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.