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 <https://groups.google.com/a/chromium.org/g/blink-dev/c/5SZB2CFFGqE/m/-mtBskjyAgAJ> to enable this by default. I'll flip the switch next Monday unless I hear otherwise. François On Wed, Mar 1, 2023 at 11:36 AM Alex Russell <slightly...@chromium.org> wrote: > LGTM3 > > On Wednesday, March 1, 2023 at 8:34:52 AM UTC-8 Yoav Weiss wrote: > >> LGTM2 >> >> On Wed, Mar 1, 2023 at 5:34 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> 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! >>> >>> On Tue, Feb 28, 2023 at 7:32 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> 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? >>>> >>>> On Mon, Feb 27, 2023 at 8:24 PM 'François Doray' via blink-dev < >>>> blink-dev@chromium.org> wrote: >>>> >>>>> 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 >>>>> <https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds> >>>>> . >>>>> >>>>> 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 >>>>> On Monday, December 5, 2022 at 11:28:25 AM UTC-5 François Doray wrote: >>>>> >>>>>> 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? >>>>>> >>>>>> >>>>>>> >>>>>>>> Rick >>>>>>>> >>>>>>>> On Wed, Nov 16, 2022 at 12:13 PM Daniel Bratell <brat...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> On 2022-11-11 17:56, François Doray wrote: >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-nesting-level>" >>>>>>>>> greater than 5 are affected. A timer set from the visibilitychange >>>>>>>>> event >>>>>>>>> handler, for example, won't be affected. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Nov 9, 2022 at 12:02 PM Philip Jägenstedt < >>>>>>>>> foo...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> 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? >>>>>>>>>> >>>>>>>>>> On Tue, Nov 8, 2022 at 10:10 PM François Doray < >>>>>>>>>> fdo...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1186569#c16> >>>>>>>>>>> ). >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? 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. >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> 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/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>>> 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/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>> 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+unsubscr...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUhYHKBk9nMJs7dCORDP_NZPEabrnxUe42emDJhrmkixA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5GTc0FyK3cDtBQ5aCzK2FM3NruSR5y%3Dfe-B3QQXCE_xpw%40mail.gmail.com.
