Intent to Ship: Quick intensive timer throttling of loaded background pages

[François Doray]

Contact emails

jiahe...@intel.com, fdo...@chromium.org

Specification

https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Design docs

https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit

Summary

Enter Intensive Wake Up Throttling after 10 seconds if the page is fully loaded when it becomes hidden. Currently, wake ups from JS timers with a nesting level >= 5 are throttled to 1 per minute after the page has spent 5 minutes in the background [1], which is very conservative and was chosen to allow a launch of Intensive Wake Up Throttling with minimal regression risk. We're now planning to reduce this timeout to 10 seconds if the page is fully loaded when hidden. [1] https://chromestatus.com/feature/4718288976216064

Blink component

Blink>Scheduling

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals: The more conservative version of Intensive Wake Up Throttling shipped smoothly to 100% Stable more than 1 year ago. A few bugs were filed, but in all cases we've been able to propose workarounds which made apps more efficient (example).

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No, this feature will not ship on desktop platforms.

Debuggability

This is not a new Web Platform feature.

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

No

This feature will only ship on desktop platforms. On Android, the system severely limits resource consumption in background renderers, which makes this feature unnecessary.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

quick-intensive-throttling-after-loading

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1324656

Estimated milestones

DevTrial on desktop Enabled by default on desktop

104 109

 

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5580139453743104

Additional context

The 1% stable experiment shows that this feature reduces Chrome's CPU usage and extends battery life, as desired. We plan to enable it by default in M109.

The 1% stable experiment is still ramping up, so we would like to keep experimenting in M108, to get small confidence intervals for all our metrics on all desktop platforms.

[Philip Jägenstedt]

The potential compat risk of this seems significant, if it means that pages can start misbehaving or breaking after 10 seconds in the background, which seems common in workflows like logins or ecommerce, where you might be flipping back and forth between tabs to find passwords, confirm credit card transactions, etc.

Have there been any bug reports from the beta experiment yet? To increase confidence, can we run this experiment at 100% on beta, dev and canary for a few milestones before trying it on stable? Are there any other ways we can gain insight on the compat risk?

--
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/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com.

[François Doray]

We are experimenting on 1% stable since the beginning of October 2022 (M106+). We are also experimenting on 50% of Canary/Dev/Beta since June 2022. Enabling on 100% of Canary/Dev/Beta for a few milestones sgtm, if we think it will help identifying issues. So far, no bug reports have been routed to me.

Note: Only timers with a "nesting level" greater than 5 are affected. A timer set from the visibilitychange event handler, for example, won't be affected.

[Daniel Bratell]

Hi François,

We [MikeT, Rick, Yoav, Chris and I] discussed this on the API Owners meeting and there were some things affecting user experience I was concerned about.

Looking at the maximum perceived impact to the user, that would be that the user is putting a tab in the background, but expecting some kind of event in a couple of seconds. If that event depends on the throttled timers, that event could, worst case, with this change be delayed from 10 seconds to 1 minute (or 10 seconds + 1 minute?). Before this change, worst case would be that some event would be delayed from 5 minutes to 6 minutes.

I consider, from a usage perspective, a delay from 5 to 6 minutes (worst case) acceptable if there are other benefits to the delay, but a change from 10 seconds to 1 minute (worst case) seems much more impactful since it would be fivefold increase in waiting time.

Considering that, have you investigated if there is some kind of middle ground where a smaller change would get more or less the same benefit to battery life? Or is there some other more advanced gradual throttling that could make the worst case less bad? Or do you have data that shows that my concern is irrelevant in some way?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com.

[Rick Byers]

Thinking some more about this, perhaps it really comes down to what the nesting level >5 criteria means in practice? I guess metrics on how common such tasks are won't be helpful because if they weren't common then it wouldn't be attractive for power savings. But do you have anecdotal experience suggesting that user-important events like Daniel and Philip are worried about tend to be a lower nesting level, while things like analytics and ads tracking tends to be higher nesting level? Any idea what data went into the selection of "5" as the threshold?

It looks like there are other important heuristics too, like timers started in network response handlers aren't subject to throttling. This is clearly pretty nuanced, not something I'd really trust our judgement to be able to accurately evaluate the risk of. Rather than try to speculate on heuristic details here, perhaps it would be more productive to try to align on the principals for how you're evaluating compat risk?

In particular, no issue at 50% beta and 1% stable seems like a pretty strong signal to me (especially relative to prior tab freezing efforts). But how confident are you in bugs reaching you? Eg. if a tester bisects based on a customer provided repo, is it likely to point to a CL you landed? Or does this being under finch control mean that a bisect won't work to identify the cause of a regression? I just searched for any bug opened in the last 180 days which mentions setTimeout and setInterval in the summary and didn't find anything relevant, so that's IMHO a significant data point in your favor. Also the example you cite from the previous change looks like it was quickly routed to you, so a good sign.

Note I think we avoid 100% trials in beta because that leaves the stable config unvalidated, so topping out at 50% on beta seems right to me. But  what's the launch plan after that? Will you go straight to 100% stable and consider backing back down if there are non-trivial reports of breakage? Or do a gradual ramp?

Reading through the prior example you cited, I suspect the randomness of finch trials could cause some frustration here - eg. some customers complaining of breakage but devs being unable to reproduce it. What would you think about ramping down the timer value predictably rather than gradually ramping up the finch trial? I.e. drop 100% of stable users from 5 minutes to 2 minutes first? Perhaps a few weeks at 2 minutes, then 30 seconds without issue would be enough to reduce fear of going to 10 seconds while still giving predictability to developers trying to figure out what's going on?

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com.

[Chris Harrelson]

Hi,

The API owners discussed this intent today. In addition to the above questions, we achieved consensus that if you were content with 1 minute instead of 10 seconds, we'd be prepared to LGTM. For 10 seconds, we have additional concerns that would require more discussion and caveats. If 1 minute achieves your goal of battery savings, could we go with that?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%40mail.gmail.com.

[François Doray]

Hi API owners,

I agree that using a 1 minute grace period (instead of 10 seconds) is less risky and will likely yield similar resource savings. We'll experiment with this new grace period and keep you updated with the results.

Side note: Chains of timers on background pages can usually be replaced with more resource-efficient APIs, see https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. We think it would be a good thing if, for example, Web content migrated from polling a server to push Web Sockets in response to tighter restrictions on timers.

More details below.

Have a nice day,

François

On Wed, Nov 23, 2022 at 12:03 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi,

The API owners discussed this intent today. In addition to the above questions, we achieved consensus that if you were content with 1 minute instead of 10 seconds, we'd be prepared to LGTM. For 10 seconds, we have additional concerns that would require more discussion and caveats. If 1 minute achieves your goal of battery savings, could we go with that?

Yes we could.

 

On Wed, Nov 16, 2022 at 5:15 PM Rick Byers <rby...@chromium.org> wrote:

Thinking some more about this, perhaps it really comes down to what the nesting level >5 criteria means in practice? I guess metrics on how common such tasks are won't be helpful because if they weren't common then it wouldn't be attractive for power savings. But do you have anecdotal experience suggesting that user-important events like Daniel and Philip are worried about tend to be a lower nesting level, while things like analytics and ads tracking tends to be higher nesting level? Any idea what data went into the selection of "5" as the threshold?

For many years, the spec has said that the timeout of a timer with a nesting level >5 is clamped to be >= 4ms. https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers We used the same criteria to apply intensive throttling.

It looks like there are other important heuristics too, like timers started in network response handlers aren't subject to throttling. This is clearly pretty nuanced, not something I'd really trust our judgement to be able to accurately evaluate the risk of. Rather than try to speculate on heuristic details here, perhaps it would be more productive to try to align on the principals for how you're evaluating compat risk?

In particular, no issue at 50% beta and 1% stable seems like a pretty strong signal to me (especially relative to prior tab freezing efforts). But how confident are you in bugs reaching you? Eg. if a tester bisects based on a customer provided repo, is it likely to point to a CL you landed? Or does this being under finch control mean that a bisect won't work to identify the cause of a regression? I just searched for any bug opened in the last 180 days which mentions setTimeout and setInterval in the summary and didn't find anything relevant, so that's IMHO a significant data point in your favor. Also the example you cite from the previous change looks like it was quickly routed to you, so a good sign.

I admit that we don't have a perfect process to ensure that bugs are routed to us. If someone experiences a problem, they could manually disable features enabled via Finch (listed at chrome://version/?show-variations-cmd). If they filed a bug with the experiment name (QuickIntensiveWakeUpThrottlingAfterLoading), we would find it. But I'm not convinced that most people would do this. We should probably include clear debug steps in release notes?

 

Note I think we avoid 100% trials in beta because that leaves the stable config unvalidated, so topping out at 50% on beta seems right to me. But  what's the launch plan after that? Will you go straight to 100% stable and consider backing back down if there are non-trivial reports of breakage? Or do a gradual ramp?

We definitely want a 1% stable experiment to confirm that this change has a positive impact. Ramping up to 50% stable gives us more confidence in the results, but going straight to 100% stable to reduce variations between Chrome clients also works.

 

Reading through the prior example you cited, I suspect the randomness of finch trials could cause some frustration here - eg. some customers complaining of breakage but devs being unable to reproduce it. What would you think about ramping down the timer value predictably rather than gradually ramping up the finch trial? I.e. drop 100% of stable users from 5 minutes to 2 minutes first? Perhaps a few weeks at 2 minutes, then 30 seconds without issue would be enough to reduce fear of going to 10 seconds while still giving predictability to developers trying to figure out what's going on?

Gradually reducing the grace period for 100% of stable wouldn't let us confirm that the intervention has a positive impact. What do you think of experimenting with the target grace period for 1% stable to confirm impact, and then launching by gradually reducing the grace period for 100% of stable until we reach the target?

[François Doray]

Hi blink-dev@!

We experimented with the "Intensive Wake Up Throttling of Javascript Timers after 1 minute in Background" feature on Stable 1%. With 7 days of ramped up data, we observe small but statistically significant changes to CPU usage. In addition to these savings, this feature encourages Web developers to replace usage of Javascript timers with more efficient APIs.

Could we ramp up the experiment to 50% of stable to measure the savings with smaller confidence intervals? In particular, we don't expect to be able to capture battery life improvements with 1% of stable.

Thanks,

Francois

[Yoav Weiss]

Thanks François for getting back to us, and I'm glad to hear we see meaningful improvements with the 1 minute throttle.

From a web compat perspective, this *shouldn't* be highly observable, so assuming you haven't gotten bug reports or saw an uptick in some other metrics that can indicate this is causing an issue for backgrounded pages, I think it's fine to experiment with this for a larger population set, to get more meaningful results.

In terms of the Blink process though, I'm not 100% sure what we want to do here, given that this is an intent to ship. Maybe best to send an intent to experiment with the exact experiment details you want to run. Would that be too much overhead?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.org.

[Chris Harrelson]

LGTM1 to ship. The API owners met today and it's fine to run a 50% experiment as part of the rollout. Thanks for the detailed work!

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

[Yoav Weiss]

LGTM2

[Alex Russell]

LGTM3

LGTM2

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/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.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.

[François Doray]

Hi Blink API owners,

The experiment has been running on 50% of stable for 4 weeks. There are no regressions to guiding metrics on any platform and I'm not aware of any breakage. Median CPU usage is reduced by 1% on Windows and Mac. 

IIUC, I already have your LGTM to enable this by default. I'll flip the switch next Monday unless I hear otherwise.

François

LGTM3

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.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/CAL5BFfUhYHKBk9nMJs7dCORDP_NZPEabrnxUe42emDJhrmkixA%40mail.gmail.com.