This intervention was enabled for some time on perf waterfall, Dev and Canary channels (as ExpensiveBackgroundTimerThrottling Finch study). There are 3 LGTMs on intent-to-ship from Blink API owners: https://groups.google.com/a/chromium.org/d/msg/blink-dev/XRqy8mIOWps/LvBUbWbxAQAJ

Summary:
Some badly behaved pages (e.g. javascript ads and analytics scripts) consume a lot of CPU even when the tab is in the background, impacting browser performance and battery life and ruining user experience. The idea is to place a limit on how much processing resources background pages are allowed to use.

The proposed throttling operates as follows: 
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).

Is this actually shipping in Chrome 56?  This bug is still "assigned", the chromestatus entry still says "in development" and I don't see it mentioned at all in the M56 breaking changes post: https://developers.google.com/web/updates/2016/12/chrome-56-deprecations

Given this lack of communication with web developers and the reports of breakage on blink-dev (https://groups.google.com/a/chromium.org/d/msg/blink-dev/XRqy8mIOWps/kh-YLvtLAwAJ), I'm concerned that this is not really ready to ship to stable in a couple weeks.  Is there outreach that I'm missing?  Should we quickly disable on the M56 branch to give ourselves some more time to do the outreach etc?

Overall I think is a really important and useful feature for user experience, having unknown computation running in the background eating CPU is pretty crummy. However I have written some older apps (moderately complex enterprise webapp) that would be adversely affected by this change.

As user, though, I really like the notion of throttling tabs that are running in the background and wasting battery and eating cpu. 

So to me the fundamental issue is one of user control. If the user wants the site to run in the background, great. However a lot of times they don't even know that it is and, surprise! the battery is drained, or everything is running slow and it's time to press shift+esc and stare at the jumping percentages in the task manager.

So to that end, communicating what's going on to the users, is I think pretty important so hopefully:

* A Visual Indicator on the tab, similar in spirit to the speaker or red recording circle, that conveys
 1. Tab is fully utilizing its throttle.
 2. Tab has throttling disabled by user-request.

And then to give users control:

* The ability via `site settings` to disable the throttling, however if a site is using excessive background resources, some sort of ui should show indicate such.

(A lot of this would be almost trivial by showing little cpu use bars, with a line where the throttle is, but it might look kind of ugly)

Anyhow, I am glad to see chromium getting out ahead of this, I think this stuff is going to get worse as sites seek to run more code on our machines in ways we cannot easily discern. So I actually don't like the suggestions that workers / websockets / audio work around aggressive throttling without user consent, because the bad actors are just going to use that to burn cpu in the background without the users consent. However breaking any site with a websocket on it, unless something is opted into, may be worse. I guess trying different approaches and seeing which works best might be the best way forward.

The risk I'm concerned with here primarily impacts desktop browsers (on mobile background tabs are already heavily throttled/suspended).  Adding desktop OS labels for the purpose of M56 ReleaseBlock.

+bustamante for desktop explicitly since they're cutting REAL soon (if not already).

I remember when Safari implemented background throttling a while back (https://webkit.org/blog/96/background-music/ ). There was a bit of negative feedback at the time because it "was slower" so avoiding such accusations will be half the battle...

Please also treat tabs with active WebRTC DataChannel connections as exempt. We've already run in to trouble with hosting multiplayer games in background tabs, as described in  issue 676036 , and from what it sounds the proposed CPU budget will be far too small to keep processing a game.

Is this feature ready for testing? 
If yes, please respond to test survey - https://docs.google.com/document/d/1JWSU0DvOaIkcPb4GERyDrdVNgG_G0U0vwRwj4_5tiiY/edit

FYI: We are cutting M56-Stable RC today 01/24, 4.00 PM PST.

Yeah we're cutting the build in a couple hours, I read through the discussion in launch review thread and it sounds like this has been through significant reviews with the code being live on perf waterfalls, live on dev channel, and it went through blink review.

I don't think we should block M56 on it, if they're just doing a stable experiment.

Yes it sounds like the parameters (and so risk) are totally controllable via finch so there's no need to block m56 release on this afterall (worst case we can just disable via finch).  Sorry for the false alarm.

Context: 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/XRqy8mIOWps/Y7BfqTHVBAAJ
https://groups.google.com/a/chromium.org/d/msg/intervention-dev/Lzc7vvpfDpQ/Cc_tE6wXCgAJ

Alexander, please update this bug ASAP to indicate whether the finch config will remain on for M56 (mark as 'Fixed' and update https://www.chromestatus.com/feature/6172836527865856 accordingly) or we'll punt to M57.

We are not going to ship this in M56 stable due to the issues around websockets.

The current plan is to stop aggressively throttling pages with active connections and ship this intervention in M57.

P.S. Please note that experiment is still enabled in 20% of beta with an upper limit to maximal throttling delay of 30 seconds.

Please make sure that when you introduce such throttling there's always a command line flag to disable it. Otherwise it's a nightmare for developers as running a simple Karma test suite in Chrome in watch mode is going to fail all the time once the Chrome window goes in the background.

This has been a problem in the past, it led to a creation of the --disable-background-timer-throttling flag. But even with this flag Chrome is *still* throttling something on macOS and some of my colleagues are unable to test on Chrome locally because of this issue.

@15: --disable-background-throttling flag should work (and will continue to work with this intervention). If something if throttled, please file a bug with a repro, I will look into that.

Re #c16: there already is an issue about this problem: https://bugs.chromium.org/p/chromium/issues/detail?id=605498

I think there should be an ability to mark specific tabs or domains as "unthrottled", also domains that are allowed to show notifications, or have access to camera or microphone should have a special mode or at least bigger budget or so. WebRTC active audio\video MUST be an exception, in my opinion. WebRTC Data channels are the more complicated question, I have already seen how ads are loaded via data channels to fool AdBlock, and how statistics and metrics are gathered via data channels.
Still, what will be the impact for WS connections, what about BOSH or COMET?
Now I suspect there will be tons of ads with soundless sound, dummy WS connections and some other ways to fool this.

Re #18: As mentioned in #14, tabs with active connections (websockets, webrtc) will not be throttled. Soundless sound will not grant exception, only audible sound (user will see a traditional "tab is playing audio" icon).

Does the definition of Active Connections cover long held http as used in XHR long polling. Many applications use this instead of websockets.