Intent to Implement: [Intervention] Stop loading in background, on mobile

214 views
Skip to first unread message

Shubhie Panicker

unread,
Oct 31, 2017, 8:47:33 PM10/31/17
to blink-dev

Contact emails

pani...@chromium.org


Design doc/Spec

Design doc

WICG Interventions issue


Summary

Intervention: Loading tasks in blink scheduler and fetching of resources will be stopped (100% throttled) when a renderer has been in the background after grace time of 5 minutes, on Android (only).


Motivation

Many sites continue loading activity, even after their app has been in background for over 5 minutes.. This consumes non-trivial amount of CPU and network bandwidth, and hurts the responsiveness of the foreground app, especially on mobile.

Our data (UMA) shows that loading task queue is the largest contributor (amongst attributed tasks) to work in background, and this work continues even after 5 minutes.


Earlier this year, we stopped timers in background, on Android. Ultimately, we want to stop almost all background work, after a grace time, on mobile and desktop, under the Lifecycle umbrella project. Stopping loading on Android, is an incremental step on the path towards stopping background work.


Risks

Compatibility

Compat risk: medium

This intervention is not expected to impact end users much. An opt-out (limited time) will be provided for apps that encounter problems. The opt-out will be extended as needed, for legitimate use-cases.

We will run a Finch experiment to find any unexpected sources of breakage, and analyze metrics.


Loading work in background tabs, is generally not visible to mobile users. Background loading is less common on mobile. Furthermore we wait for a generous 5 mins, before intervening here.

Resource fetches and scheduler tasks are queued up, and will be resumed if the user brings the site to foreground, so there is no breakage of content.

            

Interoperability

For long term interop on stopping (and discarding) in background, we are working with other browser vendors on Lifecycle (see Intent to Implement thread).


Intervention Guidelines

Predictability

The mechanism is well defined and predictable, same as stopping timers in background. (The behavior will be eventually spec’d as part of Lifecycle)

Avoidability

Continuing to be loading in background after 5 minutes is not a good practice, especially on mobile (for data and battery).

Transparency

We are working on a JS callback to notify the app when the page transitions to STOPPED state in background. We are looking into firing a console message or notification via Reporting API.

Data-driven

See current thoughts on success and regression metrics here.


Debuggability

A console message will be emitted when the intervention is triggered. As well as a JS callback.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This intervention will be implemented on Android only, for now.

(Eventually background work will also be stopped on desktop)


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6238781036298240


Requesting approval to ship?

No.


Yoav Weiss

unread,
Apr 25, 2018, 4:52:53 AM4/25/18
to Shubhie Panicker, blink-dev
It makes sense to explore interventions and solutions in that space, as users rarely suspect that background tabs are eating away at their CPUs and data plans.
At the same time, we need to provide some ways for sites/users to opt-in to background loading tasks. We've discussed this when discussing throttling of background worker tasks. I think it'd make sense to think of similar (or even the same) opt-in here.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi8y-4FTtTZTpznOeZXJd2AzsEEDS96qExDgWej7xKpzdQ%40mail.gmail.com.

Harald Alvestrand

unread,
Apr 25, 2018, 5:05:42 AM4/25/18
to Yoav Weiss, Shubhie Panicker, blink-dev
Will this affect people running (for instance) spotify in a background tab?
(Hangouts uses webrtc, so I assume it and apps like it won't be affected by this, but audio apps that do chunk-at-a-time loading may be hard to distinguish from other backgrounded apps that want to load data.)


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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiKELe0cXCF8w2aysa3TYqsaFxTv84iE2Ggurs4ROfVXQ%40mail.gmail.com.

Shubhie Panicker

unread,
Apr 25, 2018, 12:05:11 PM4/25/18
to Yoav Weiss, blink-dev
Hey Yoav,
Do you have specific use-cases in mind for opting into loading on mobile *after 5 mins*?
We already use heuristics to allow legitimate usecases (and allow background audio etc).

Developer opt-out and user opt-out are both in the pipeline as they are needed for upcoming, more aggressive interventions - for desktop.
The developer opt-out would work for mobile too, but not the user opt-out.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Shubhie Panicker

unread,
Apr 25, 2018, 12:06:01 PM4/25/18
to Harald Alvestrand, Yoav Weiss, blink-dev
On Wed, Apr 25, 2018 at 2:05 AM, Harald Alvestrand <h...@google.com> wrote:
Will this affect people running (for instance) spotify in a background tab?
Nope, Tabs with background audio are not eligible for this intervention. 

Daniel Bratell

unread,
Apr 26, 2018, 9:15:30 AM4/26/18
to Harald Alvestrand, Shubhie Panicker, Yoav Weiss, blink-dev
I think it's those exceptions (audio/webrtc) that need to be clear to web developers. Right now I don't know if they are documented in anything but mail threads and C++ source code and random design documents.

Another exception that has been mentioned is notification access. If a user has allowed a webapp to send notifications, that webapp may (or maybe not) do something that the user wants to happen all the time, not only when they watch it.

/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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+...@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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi_TdgDEuO-bfA-rXERR5mx0b61hWK6vV%3DLPargigMZRkQ%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Shubhie Panicker

unread,
Apr 27, 2018, 8:53:12 PM4/27/18
to Daniel Bratell, Harald Alvestrand, Yoav Weiss, blink-dev
On Thu, Apr 26, 2018 at 6:15 AM, Daniel Bratell <bra...@opera.com> wrote:
I think it's those exceptions (audio/webrtc) that need to be clear to web developers. Right now I don't know if they are documented in anything but mail threads and C++ source code and random design documents.
Happy to document this better. There are two aspects:
- documentation of the interventions of freezing and discarding: 
the idea is to standardize this, this is already being done on the Lifecycle explainer and in-progress spec (freezing and discarding). Feel free to file spec issues for clarifications. 
The spec provides guidance and examples for how these interventions should trigger, and when to not trigger them (eg. background audio). However it is up to each UA as to the specific criteria for triggering freezing (and discarding) and what heuristics they use.

- this raises the second point: documentation of specific behavior in each browser.
Today browsers (eg. Edge, Safari etc) already do freezing / CPU suspension however it is not documented anywhere AFAIK.
For Chrome, I am happy to document the specifics. 
Where should this be documented? should there be a common place for all browsers? Suggestions appreciated. 
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.
--
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.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zh2xruwtrbppqq%40cicero2.linkoping.osa.

Reply all
Reply to author
Forward
0 new messages