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

[Shubhie Panicker]

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 when a renderer has been in the background after grace time of 5 minutes, on Android (only).

We have been running a Finch experiment over last 5 months and addressed all the issues we found there. This intent to ramp up the experiment on stable and ship it.

Our metrics show reduced CPU work in background (CPU is correlated to battery usage) and much improved foreground FCP when there are 2+tabs loading, and well as improved time to switch to background page with 2+tabs loading, and increased sample counts in these metrics indicating lower abandonment. For details see here.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/EQJX2aGVeUU/_-ldCknQBgAJ

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.

Risks

Compatibility

Compat risk: low

We have addressed issues we found in the Finch experiment (eg. service worker timeouts) and therefore updated the risk to low (was “medium” in the I2I).

            

Interoperability

For long term interop on freezing (and discarding) in background, we are working with other browser vendors on Lifecycle.

Intervention Guidelines

Predictability

The mechanism is well defined and predictable, same as stopping timers in background. Lifecycle spec will mention existing triggers for freezing.

Avoidability

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

Transparency

onfreeze / onresume callbacks will fire as part of Lifecycle API, expected to ship in next milestone.

Data-driven

For summary of metrics see here.

Debuggability

A JS callback (onfreeze) will fire when the intervention is triggered. We are also looking into exposing trigger for freezing via WebDriver API for automated testing. Currently freezing can be manually triggered and tested via chrome://discards.

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

[Shubhie Panicker]

Friendly ping.

There has been a bit of discussion on the companion Intent to Implement, but nothing here :)

[Chris Harrelson]

On the intent-to-implement thread, you mentioned that various use-cases would not get the intervention. You also mentioned that there will be an opt-out. Are either of them documented? I think this is necessary before shipping.

Also, it seems to me that sites that are affected by this intent would benefit from the upcoming Lifecycle API, as that would help with mitigations. Can this intent be delayed until after that API ships? I assume as well that the Lifecycle API explicitly allows user agents to do things like what is being proposed here, is that correct?

Chris

--
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_T-xGEoELwG7kLUsV1O5YjJ-d-pXKU5K-GLwv7AGCdGA%40mail.gmail.com.

[Shubhie Panicker]

Thanks Chris for the response!

The meta point here is that this intervention is Android only, and therefore we think it's okay due to expectations on mobile, and mobile platforms already do this kind of thing (hidden activities are suspended, background work is heavily restricted), so this is quite inline with Android lifecycle and expectations. (We were surprised how much CPU work chrome background tabs were able to get away with given current Android lifecycle)

   

Details:

- user opt-out: we don't think a user opt-out is needed for this case (we haven't found any concrete need for this on mobile), although we do think that user opt-out is needed for upcoming (similar) desktop interventions and that is being worked on.

- developer opt-out: there is no developer opt-out at the moment. Again, developer opt-out is needed for the desktop interventions and being worked on. A developer opt-out could be useful, but I'm not sure it is necessary to block this intervention, as we will pause the experiment if we find unexpected legitimate breakages in the ramp up on stable, and fix the issues before full rollout. Note that we have run this experiment on Beta for 5 months, and there are no outstanding issues.

- documentation of heuristics: happy to document this, should I put this in the intervention issue?

tl;dr: the following precludes freezing: background audio, running service worker, pending fetch keep-alive, running shared worker.

 

- benefit of the Lifecycle API:

Yes, the Lifecycle spec will make freezing and discarding a standard part of the web platform that UAs can do for resource management.

once the API is shipped, a callback would fire at the time of freezing. This section in the Lifecycle doc explains the need for the callback (shorter version here).

Much of this applies to desktop apps where freezing is a new concept, and as I said mobile web apps are already subject to CPU suspension and discarding from the OS. 

 

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

[Chris Harrelson]

Now it makes sense to me why the opt-outs are excluded for this first Android-only launch. Thanks for the clear explanation!

LGTM1

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

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8cda4Nx4Bpg0GoC93Yxy-Hs2kGAUsgEM%2BeTL5WmmoqEg%40mail.gmail.com.

--

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

[Yoav Weiss]

LGTM3

I'd love to see an eventual opt-out here, but can't think of any mobile use case that requires it and isn't already excluded using the mentioned heuristics, so agree it's not blocking.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zidrskijrbppqq%40cicero2.linkoping.osa.

[Shubhie Panicker]

Thanks all.

+scheduler-dev as FYI

On Wed, May 2, 2018 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

LGTM3

I'd love to see an eventual opt-out here, but can't think of any mobile use case that requires it and isn't already excluded using the mentioned heuristics, so agree it's not blocking.

 Are you thinking about user opt-out or developer opt-out?

 

LGTM2

/Daniel

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/CAK7ODi_T-xGEoELwG7kLUsV1O5YjJ-d-pXKU5K-GLwv7AGCdGA%40mail.gmail.com.

--
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/CAOMQ%2Bw8cda4Nx4Bpg0GoC93Yxy-Hs2kGAUsgEM%2BeTL5WmmoqEg%40mail.gmail.com.

--

/* 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.

[Yoav Weiss]

On Wed, May 2, 2018 at 6:41 PM Shubhie Panicker <pani...@chromium.org> wrote:

Thanks all.

+scheduler-dev as FYI

On Wed, May 2, 2018 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

LGTM3

I'd love to see an eventual opt-out here, but can't think of any mobile use case that requires it and isn't already excluded using the mentioned heuristics, so agree it's not blocking.

 Are you thinking about user opt-out or developer opt-out?

I haven't given it a whole lot of thought, but maybe a way for developers to ask for background processing/downloading permissions from the user?

 

 

LGTM2

/Daniel

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_T-xGEoELwG7kLUsV1O5YjJ-d-pXKU5K-GLwv7AGCdGA%40mail.gmail.com.

--
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/CAOMQ%2Bw8cda4Nx4Bpg0GoC93Yxy-Hs2kGAUsgEM%2BeTL5WmmoqEg%40mail.gmail.com.

--

/* 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+...@chromium.org.