Chrome to throttle expensive background pages
Google plans to roll out a change in Chrome Stable soon that will have the browser throttle timers in background tabs to improve battery life and browsing performance.
The core idea is to limit the processing power that background tabs get in Chrome once the feature lands.
- Each WebView has a budget (in seconds) for running timers in background.
- A timer task is only allowed to run when the budget is non-negative.
- After a timer has executed, its run time is subtracted from the budget.
- The budget regenerates with time (at rate of 0.01 seconds per second).
The only pages that appear to be exempt from the throttling are those that play audio.
While the change aims to tackle background pages that use an excessive amount of CPU, it may impact any background page, e.g. messengers, chat rooms, notification services, that does something in the background.
While Google states that the implementation won't break any functionality, some web developers think otherwise.
Samuel Reed mentions on his blog that web application timers may be delayed for minutes (Google reduced the maximum to 30 seconds in the meantime), and that this will impact popular applications like Slack or Discord.
Other web developers have voiced their concern on the official Blink Development forum as well. At least one developer raised the question whether affected sites and services would start to loop a small audio file that is inaudible to the user to avoid the throttling.
Chrome would indicate that audio is playing in its interface, but it could very well happen that sites implement this, at least in the short run.
Google did test the implementation on Gmail and did not notice any issues with the service's notification system.
Google's developers also want to make sure that cases where users are multi-tasking are unaffected (switching between different tabs regularly). Ideas mentioned by Google are to either delay the throttling for a period of time before it kicks in, or setting a generous initial budget.
Now You: What's your take on the proposed change?
Isn’t this something that Opera introduced a while ago with their Battery Savings mode?
In fact, Chrome has already added some throttling to background pages in the past few months (which is where the bug with the delayed display of extension pop-ups came from) but it will only get worse from here on out. Because there is no way to disable this, I’ve been hoping for other browsers to provide salvation. Opera does have a ‘Background tab throttling’ flag, but either it is bugged or it works differently than described since the default setting is disabled and that’s the default Chrome behavior. At the moment only in Firefox is it possible to keep timers in unfocused tabs or browser windows from being throttled.
Is it too difficult to just monitor and report–allowing each user to decide whether to throttle using a provided mechanism? My battery (and if I don’t actually have a battery), my decision.
Too complicated for the typical Chrome user.
One of the first few signs that Chrome’s architecture is feeling that heat?
Come on Rust/Servo :)
The tide may be turning!
Come on guys. Any real time game developer knows how to deal with sudden jumps in timestamps, which is the consequence of things like computer slow downs or throttling, as seen from the program being throttled.
Get your shit together, web developers. Your apps do not own computer resources any more than real time games do; good code has to assume that at any point it could be deprived of computer resources, or get less than needed.
That’s just how it is. This problem has existed and been solved for a long time now, I’m surprised web developers react the way they do.
Now, I still tend to agree with Dan82 on his first sentence, although I would say it is the result of Chrome being close to monopoly status rather than developers being arrogant.
On the other hand, ensuring backwards compatibility is a duty of web browsers as per the very definition of internet (and it is a good thing), so if throttling breaks many sites that are not maintained enough to get fixed, then it’s a problem that can only be solved progressively over the years, like the Flash migration.
But in the end, let’s consider how few sites should break from throttling. The kind of advanced code that would be hurt by it is recent, so only some recent apps should break, and those are more likely to be maintained. Which means not only that it could actually be fair to go full throttle now, but that should it not be done right now, the window of opportunity would close and we’d have on our hands another Flash migration issue that takes years to be solved.
So IMO, web devs, swallow the pill, get your shit together, and code your web app properly. I’m not sure those who complain realise how much of a problem background JS code has become.
They also could solve the Vsync issue which also can cause some battery issue, since it’s too aggressive.
The problem even gets more and more worst with the time since there now 144+ Monitors and on smartphone screen also maybe getting more Hz soon.