Contact emails
Design doc/Spec
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
--
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zidrskijrbppqq%40cicero2.linkoping.osa.
LGTM3I'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.
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.
Thanks all.+scheduler-dev as FYIOn Wed, May 2, 2018 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:LGTM3I'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+...@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.