Contact emails
Design doc
Time-based renderer task throttling
Summary
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).
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> 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.
- 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.
On 27 September 2016 at 19:28, <ben.m...@gmail.com> wrote:- 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.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).
- 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.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.
On 27 September 2016 at 19:28, <ben.m...@gmail.com> wrote:- 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.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).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.
- 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.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).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.
Exact solution and parameters are to be determined after experimenting and collecting metrics from the Web.Are you guys planning to dark launch this before enforcing?
-b
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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.
> Do you have any concerns if this can lead those badly behaving scripts to start playing audio to work around this restriction?
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.