Chrome will aggressively throttle background tabs – as a feature, not a bug

Google is continuously brushing up its Chrome browser to make it leaner and meaner, but a recently announced still-to-come enhancement has left a slew of developers worried it could affect the proper functioning of their websites.

Chromium engineer Alexander Timin has detailed a future implementation that will essentially prompt Chrome to aggressively throttle resources in background tabs in order to prolong battery life and improve the overall browsing performance.

The tweak fundamentally aims to moderate poorly behaved pages – inundated with heavy JavaScript ads and analytics scripts – by placing a limit on the processing resources allocated to background activities consumption. This ought to make background tabs drain less CPU power.

Here’s a summary of the proposed modifications as outlined by Timin:

• 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).

While the intended changes are generally a good thing, some web developers remain reserved about the plausibility of the tweaks, speculating the update will result in a litany of malfunctions once the update rolls out.

Blogger and developer Samuel Reed has voiced out his concerns the implementation could ultimately prevent a boatload of popular apps like Slack and Discord from firing (timely) notifications when running in the background. This is what Reed said:

When idle, your application’s timers may be delayed for minutes. Aside from terrible hacks like playing zero-volume sounds, you have no control over this. Avoiding expensive CPU work is not a panacea; that some applications must do significant work in the background, including syncing data, reading delta streams, and massaging said data to determine whether or not to alert the user.

Worse yet, the heuristic is based on local CPU time; faster clients may have no issue and face no throttling, but slower devices often will, causing cascading processing and notification delays.

While Timin said initial testing has gone without any problems, he himself seems to acknowledge that “there exists a possibility of breakage” for certain websites, which is why he ensures the implementation will be tested in a controlled environment before going live.

The Chromium insider also clarified that aggressive throttling will be automatically disabled for all background tabs “playing audio” as well as for any page where an “active websocket connection is present.”

Timin further adds the Chromium team has plans to exempt more signals from throttling, including metatags, pinned tabs and permissions to show notifications from user.

In short, once the throttling feature is properly integrated, it will solely affect obtrusive and CPU-heavy ads and scripts – and possibly a small number of rich web apps that will need some additional optimization in order to function properly.

As TNW developer Otto Rottier remarks, the upcoming tweak will merely require coders, involved with rich web applications, to become “more efficient as there is simply less computing power available” to toy around with. “It will force developers to employ more sophisticated methods, including web workers, animation frames and preventing redraws when possible.”

While the changes won’t make it to the next reiteration (56) of Chrome, Timin said aggressive throttling will likely land in version 57.

In fact, Google isn’t the only company contemplating enforcing throttling for background tabs. Microsoft is apparently mulling over implementing the same measure in its Edge browser, but is has yet to make a decision.

In other words, aggressive throttling might be here to stay – but as a feature, not a bug.