Contact emails
Design doc
Time-based renderer task throttling
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).
Link to “Intent to Implement” blink-dev discussion
Intent to Implement: Expensive Background Timer Throttling
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://fiddle.jshell.net/vvL0e9x3/show/light
Interoperability and Compatibility Risk
Initial testing by enabling the feature locally by a small number of developers did not expose any problems. However, there exists a possibility of breakage of a major site, so we want to ship this feature via experiment-controlled rollout. This will allow us to quickly respond to issues (if any), by changing throttling aggressiveness or disabling throttling completely if necessary.
Firefox: No public signals
Edge: Positive
Safari: No public signals
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6172836527865856
Requesting approval to ship?
Yes.
Yes, pages playing sound are exempt (that is inherited from current mechanisms to align background timers to once a second).
If WebViewImpl::setVisibilityState is the trigger, then I think web developers can simply use document.visibilityState and the related events to know when throttling may happen. To have an API to know that it has definitely happen seems nice for predictability in principle, but if aren't any known good reasons to do a lot of work on the main thread while in the background, then I'm inclined to think we should punt on that.Rick, do you have any further concerns? LGTM1 for me.On Thu, Nov 17, 2016 at 12:26 AM 'Yuri Wiitala' via blink-dev <blin...@chromium.org> wrote:I think we're good to go here for tab capture:1. There has been recent work on detecting when there is audible sound coming from the renderer, and turning off timer throttling in that case.2. During tab capture, the captured renderer is explictly *not* told when a browser tab becomes backgrounded. Thus, a captured renderer should always behave as if it thinks it's in a foreground tab.3. Otherwise, I think the proposal here can only improve the tab capture experience. For example, if a badly behaved page's JavaScript is eating up CPU, we want the new throttling logic to engage so that we have more CPU for capture and real-time video encoding (which will improve quality).On Tue, Nov 15, 2016 at 4:31 PM, mark a. foltz <mfo...@chromium.org> wrote:+miu as an FYI. We should make sure tabs with an active content capture device are exempted as well, if they aren't already.On Mon, Nov 14, 2016 at 4:26 PM, 'Alexander Timin' via blink-dev <blin...@chromium.org> wrote:Background tabs on Android are suspended after 5 minutes in background. Minor improvements may happen, but major win is expected on desktops.Background tab is the one which is not visible to the user (WebViewImpl::setVisibilityState is the source of truth); unfocused windows are considered foreground. This mechanism is the same as currently exists for background timer alignment.
Audio-playing sites are exempt from throttling (even after for some time after audio stopped playing).Also for your convenience I copied intervention guidelines here:Predictability: Throttling mechanism is well-defined. High-level description (only pages with significant CPU load are going to be impacted).Avoidability: Heavy computations on UI thread is not best practice, so only bad-behaved pages are going to be impacted.Transparency: Console log message is generated when tasks we throttled for non-trivial amount of time (small throttling is not reported because we already align timers in background tabs). Also developer can monitor start time of tasks and detect intervention programmatically.
Data-driven: Main UMA metric that we are monitoring is BackgroundMainThreadLoad. It is percentage of time that renderer spends executing javascript tasks. Given that >90% of pages have low CPU usage, we are expecting changes to high percentiles (95, 99), not average (95 percentile is 10% load, 99 percentile is 90% load).
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
January 20, 2017 at 3:48 AM
January 19, 2017 at 4:16 PM
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/XRqy8mIOWps/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.
Re: tuning, yes, this is an effort I am starting anew, but we already do quite a bit of good-citizen work that I wouldn't expect most applications to do: we are coalescing real-time updates and batching renders at requestAnimationFrame, we have a highly optimized view pipeline that only does minimal work on change, and so on.
if(IE){ fallback() }
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
Alexander, can you please clarify a couple points about the design (I think there's some confusion on this thread):
- It's only timers (i.e. application polling) that are throttled, right? Eg. in the case of an active websocket (or other network connection) when a network response is received, it's still given to the application immediately as normal.
- If a user (eg. for the trading app discussed here) really wants to allow the tab to do expensive timer-based polling, they can always drag that tab out into it's own window. It will then be considered a "foreground" tab and will not have any throttling applied. That's certainly the behavior I'm seeing on your demo page.
To respond to your concerns we will be limiting maximal throttling delay to 30 seconds effective now. Also we will be looking into disabling aggressive background throttling for webpages with active (e.g. websockets) connections.
... and since this behavior is entirely heuristic and can be killed by simply playing silent audio or using a WebSocket connection, I wouldn't put it past some to simply just do that to keep things working "properly."
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.
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.