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/CAOMQ%2Bw-d3qRZ%2BtuOHBHyp%3DZ-HjnaLYyUwbNhQzjuWvwgfW2LNg%40mail.gmail.com.
