Intervention: Throttle expensive background timers

[altimin]

The idea is to limit how much CPU can a backgrounded page use.

Chrome is experimenting with the idea. IE/Edge might be interested in this.

Current idea how to do it in Chrome:

• Each web page has a time budget (in seconds) for running timers in background.
• A timer task is only allowed to run when the budget is non-negative.
• After timer is executed, its run time is subtracted from the budget.
• The budget regenerates with time (at rate of 0.01 seconds per second).

/cc @skyostil @ojanvafai

[brheenan]

Edge is considering something along these lines as well. Feels like a natural progression after clamping timers to 1Hz. Our implementation is different, but it's the same principle and goal. Continue to cut down on CPU costs of background tabs in cases where timer clamping doesn't do enough.

[ojanvafai]

Would you be willing to share the details of what you plan on doing? I don't think we need to be aligned while we are experimenting with what is web compatible, but it would be good for web developers if we eventually landed in the same place.

[brheenan]

Yes, we'll share what we're planning when we have more definitive plans. I agree that we don't have to start doing the same thing (in fact, it's better to allow UAs to experiment a bit in this space). My current mindset is that the background tab should behave as though it's on a slower computer, but any intervention here should not introduce any functional bugs. We're not refusing to run websites' code, just allowing it to happen slower in exchange for better battery life and performance on the active tab.

[altimin]

We tried to enable this in Chrome 56 Beta and this generated a lot of interest from web developers who voiced concerns about legitimate usages of background processing.

In response to this concerns we are going to exempt pages playing audio or having active connections (websockets, webrtc) in the initial implementation, ship it in Chrome 57 and iterate from there.

[tommck]

It would be nice to add a command-line switch or something to disable this so that things like the karma-chrome-launcher can still run with full CPU. We don't want to slow down developers running unit tests.

[altimin]

@tommck: Agreed. Chrome already has --disable-background-timer-throttling flag for this.

[tommck]

oh great, thanks!

[sstrgh]

will the --disable-background-timer-throttling flag be a permanent fixture to manage background timers? or is the team looking to eventually remove that flag?

[ojanvafai]

It's hard to say we'll never remove the flag. As other tooling emerges for the headless/testing use case, the need for the commandline flag lessens. If it then appears the need for the flag is completely gone, we might remove the commandline flag at that point. We don't have any current plans to remove it though.

[altimin]

This was enabled on 99% of Stable channel in Chrome 57. Here's our announcement: https://blog.chromium.org/2017/03/reducing-power-consumption-for.html

(Can someone please add "Chrome-Shipped" label)?

[toddreifsteck]

@altimin @ojanvafai Any pushback from web devs or users after the throttling has been out for a few months?

[altimin]

@toddreifsteck We haven't encountered any problems with throttling timers (setTimeout/setInterval), but there were some problems when we started throttling (accidentally) other types of tasks.

[ojanvafai]

@toddreifsteck you can see some pushback on the earlier version we were trying to ship on the blink-dev intent thread, but we made active webrtc and websocket connections prevent throttling and haven't heard complaints since that I can recall. I've been pleasantly surprised. :)

As @altimin said, we're planning on extending throttling to other task types (e.g. loading tasks, indexeddb tasks, etc) and expect we'll need to tweak how this work to minimize breakage.

[johannhof]

(As noted in https://github.com/WICG/interventions/pull/72, we intend to archive this repository and are thus triaging and resolving all open issues)

I filed https://github.com/whatwg/html/issues/7941 for further standardization and linked to this issue for context.