+Scott Haseley <shase...@google.com> as an expert in this field. We would like to start experimenting with this intervention on 1% Stable very soon. We've been experimenting on 50% of Beta for almost 2 months. The results are encouraging and we aren't aware of negative Web developer feedback. Do we need your LGTM to proceed?
On Mon, Aug 1, 2022 at 3:45 AM Zhang, Jiahe <jiahe.zh...@intel.com> wrote: > Contact emails > > jiahe.zh...@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 > > Not applicable. This feature changes the behavior of an existing API, > while remaining spec-compliant ("Optionally, wait a further > implementation-defined length of time. > <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout> > ") > > 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 only ship on desktop platforms. > > > > Goals for experimentation > > We plan to experiment on 1% Stable to confirm whether we observe the same > memory and power improvements as in the lab and on lower channels. We will > decide whether this intervention ships based on the experiment data. > > > > Ongoing technical constraints > > None > > > 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 from 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 > > 105 > > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5580139453743104 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5E9r%2BjOcMa5nR3ZgYjNykEyj8bUBmjvszgFYmiBJKP-dA%40mail.gmail.com.
