| Intent to Implement: Expensive Background Timer Throttling | Alexander Timin | 27/09/16 10:41 | Contact emails Design doc Time-based renderer task throttling Summary The proposed throttling operates as follows:
Motivation 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. Interoperability and Compatibility Risk Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded). Pages using timers to modify favicon (e.g. Gmail) and conditionally play audio (e.g. all messengers) are of a main concern. We believe that our implementation will not break this functionality (preliminary testing shows that GMail works), but might delay some notifications if the background page is using a lot of CPU time. Another use case that can be impacted is when user opens a page, switches to another and expects former page to load in background. We mitigate this by only throttling timer tasks; other tasks such as loading tasks will continue to run unthrottled. Firefox: No public signals. Edge: No public signals. Safari: No public signals. Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes. OWP launch tracking bug Link to entry on the feature dashboard https://www.chromestatus.com/feature/6172836527865856 Timer throttling demo: https://fiddle.jshell.net/vvL0e9x3/show/light/ Requesting approval to ship? No |
| Re: [blink-dev] Intent to Implement: Expensive Background Timer Throttling | Majid Valipour | 27/09/16 11:16 | > Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded). Do you have any concerns if this can lead those badly behaving scripts to start playing audio to work around this restriction? (The audio may potentially be created with a low enough gain to avoid detection by user, here is my quick demo). I suppose this is more of a concern if these background tasks are important to the script and there is no other (better?) alternative to them. Majid |
| Re: Intent to Implement: Expensive Background Timer Throttling | ben.m...@gmail.com | 27/09/16 11:28 | - It'd be really helpful for a site to be able to have some sort of insight about if they are being throttled or not. If a site is being throttled they may want to investigate the cause of their CPU utilization. I'd really hate to see this shipped without some sort of debuggability. - What initial budget will a site get? It'd be helpful to give sites a generous budget of timer CPU time when the user first switches away. A user might be multi-tasking (and want to switch to and from the tab). Also if a user opens a tab in the background throttling timers right way could fundamentally alter the loading behavior of some sites. - Could setTimeout(0) be excluded from this, as long as the task that does the setTimeout is not itself a timer? Often times sites use setTimeout(0) to run a task in the next cycle of the event loop or as part of an abstraction. |
| Re: [blink-dev] Intent to Implement: Expensive Background Timer Throttling | Alexander Timin | 27/09/16 12:58 | On 27 September 2016 at 19:15, Majid Valipour <maj...@chromium.org> wrote: I don't think that it's going to be a big problem — one reason that is user can see that a background tab is playing music and close offending tab. But thank for your concern, I'll consider adding a metric to measure this and we will act if we detect that bad scripts are intentionally doing it on a large scale. And there is an alternative — Service Workers. They should be the way to do things in background and UI thread is supposed to be for UI (which means it is not needed in background). Alexander |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Alexander Timin | 27/09/16 13:25 | Thanks, you've made very good points here!
On 27 September 2016 at 19:28, <ben.m...@gmail.com> wrote: Informing developers that they are throttled are one of our top priorities. Currently we are going to do two things do achieve that: - Adding detailed information about throttling to traces, so it's easy to understand why and how a site is throttled. - Writing a console.log message when site is throttled. (Exact details are to be discussed).
Yes, we want to make sure that this use case is unaffected. Two main ideas here are: - Do not throttle page for some time after it's backgrounded (15 seconds?). - Set a generous initial time budget (several seconds? Main load is expected to be on loading task queues, not timer task queues). Exact solution and parameters are to be determined after experimenting and collecting metrics from the Web.
A very interesting suggestion which needs more consideration. I'd like to mention that in Chrome setTimeout(0) in fact is setTimeout(1). |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Ben Maurer | 27/09/16 13:43 |
I think that some sort of programmatic notification is also really important so that a developer can realize in aggregate how much throttling is an issue.
Sometimes timers end up getting used early in the page life cycle (eg in FB as part of installing chat). I'd want to make sure that throttling doesn't distort the behavior or reorder timers WRT non-timer events.
Are you guys planning to dark launch this before enforcing? -b |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Sami Kyostila | 28/09/16 09:25 |
I think we're open to suggestions what this API could look like (PerformanceObserver-based perhaps?), but I just wanted to mention that developers can measure the lateness of their timer callbacks to observe the effect of throttling.
Note that timers in background tabs are already being throttled to 1 Hz in most browsers, so this type of reordering has been happening for a good while.
As in measuring-but-not-enforcing? We've kind of already done that based on UMA data, but I think we'll still need to figure out the exact launch plan -- this is just an intent to implement :)
- Sami
|
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Harald Alvestrand | 28/09/16 11:16 | Will timers that aren't run be delayed or aborted? If delayed, the effect should be the same as when running on a host with 0.01 times the country speed - if aborted, correctness will suffer in more cases. |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Alexander Timin | 28/09/16 15:08 | On 28 September 2016 at 19:16, 'Harald Alvestrand' via blink-dev <blin...@chromium.org> wrote: Timers will be delayed — we do not cancel any timers due to correctness reasons. |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | vi...@useloom.com | 24/01/17 09:30 | How will this affect the background pages of Chrome extensions? Or will it not affect those at all? |
| Re: Intent to Implement: Expensive Background Timer Throttling | rob...@hometeamcare.com | 24/01/17 10:01 | I would love it if there was a way to override this for particular tabs, or globally to turn it off. I work at a business that has an internal web app that requires periodically polling an endpoint. This may quickly exceed 1% of the CPU time in the background, and I'd love to be able to just instruct our employees to disable throttling for our internal app.
|
| Re: Intent to Implement: Expensive Background Timer Throttling | andre...@airts.co.uk | 25/01/17 11:57 | We're in a similar situation to Rob - we develop apps exclusively for internal corporate use and they make heavy use of websockets. These are always running on desk-based machines (so battery life is a non-issue). It would be very useful to have some administrative control, so that the default behaviour could be overridden or at least the budget for certain domains could be increased. Otherwise this well-intentioned concept will be creating a lot more problems for us than it will be solving. Regards Andrew |
| Re: [blink-dev] Intent to Implement: Expensive Background Timer Throttling | bytec...@gmail.com | 25/01/17 12:50 | > Do you have any concerns if this can lead those badly behaving scripts to start playing audio to work around this restriction?
I can't speak for Chromium, but I believe Chrome itself only shows the "audio playing" UI if the audio source's volume is above some threshold. When watching videos with quiet parts, I've seen the loudspeaker icon fade out. I could be mistaken, though. |
| Re: Intent to Implement: Expensive Background Timer Throttling | Martin Chaov | 26/01/17 02:22 | Then start writing properly optimized code... |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Alexander Timin | 26/01/17 03:02 | Chrome extensions are not affected. |
| Re: [blink-dev] Re: Intent to Implement: Expensive Background Timer Throttling | Vinay Hiremath | 26/01/17 03:22 | Awesome! Thanks for the clarification. |
| Re: Intent to Implement: Expensive Background Timer Throttling | rohan...@gmail.com | 05/08/17 17:31 | Hi, I would like to run with more aggressive background throttling not less, but I am willing to turn it on manually. I would like a Chrome preference or plugin to throttle and renice all background tabs (including those with websockets and possibly audio) and let me unthrottle the ones that are important to me by right clicking on the appropriate tab in the Chrome Task Manager, or by right clicking on the tab's name in the top of the window. I would be interested in comparing my CPU usage this way to what I get when I run The Great Suspender. Thanks, -rohan
|
| Re: Intent to Implement: Expensive Background Timer Throttling | vin...@logic-square.com | 19/08/18 14:13 | Would it make sense to provide 3 options to the users a) Power Save Mode (throttling as proposed) b) Best Performance Mode (new feature turned off) c) Custom (selective throttling - users can add exceptions etc.) |