*Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames*
Contact emails zheda.c...@intel.com, fdo...@chromium.org Specification https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html Summary Align wake ups of JavaScript timers for unimportant cross-origin frames. Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to performance concerns. This is very conservative and actually some unimportant frames are eligible to use JS timer alignment. WebKit uses the policy to align DOM timer of non-interacted cross origin frames to 30ms. This feature adds JavaScript timer wake up alignment for unimportant frames on foreground pages. Unimportant frames means they are cross origin, visible but have non-large proportion of page’s visible area, and have no user interaction. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4589092 Blink component Blink>PerformanceAPIs>Timers <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3ETimers> TAG review None TAG review status Not applicable Risks Interoperability and Compatibility None *Gecko*: No signal *WebKit*: No signal *Web developers*: No signals *Other signals*: 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? None Debuggability None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? No Flag name on chrome://flags None Finch feature name ThrottleUnimportantFrameTimers Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/40942028 Estimated milestones Shipping on desktop 123 DevTrial on desktop 121 Shipping on Android 123 DevTrial on Android 121 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). None Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5106220399853568 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. On Thursday, March 7, 2024 at 12:15:41 PM UTC+8 dom...@chromium.org wrote: > Switching to an Intent to Ship sounds good. Can you update the process > stage in the ChromeStatus tool, fill out any necessary fields that differ > between the stages, and either start a new thread, or paste the > newly-generated Intent here? > > On Thu, Mar 7, 2024 at 2:48 AM Etienne Pierre-doray <etie...@google.com> > wrote: > >> I'm working with Zheda and Francois to get this feature out, chiming in >> >> In general, I think it's best to file a formal Intent to Ship if you want >>> to go to 50% stable. >>> >> I agree, I'd consider this feature ready to ship, we have enough >> confidence from previous stable experiments to roll it out. >> The main reason for doing a 50/50 experiment first is to more accurately >> measure impact on CWV. >> There aren't clear guidelines from finch otherwise on the exact % when >> ramping up from 1% to 100%, or when intermediate steps are needed at all; >> our team has been following a 1/50/100 pattern (we received feedback for >> other features that fewer intermediate steps was desirable for web devs). >> For blink purpose, I'd suggest we switch this to an 'Intent to ship'. >> >> On Mon, Mar 4, 2024 at 5:06 PM Domenic Denicola <dom...@chromium.org> >> wrote: >> >>> In general, I think it's best to file a formal Intent to Ship if you >>> want to go to 50% stable. To me it sounds like that might be reasonable >>> here? I.e. you're fairly confident that the feature is a good idea to ship, >>> but you want to do a more cautious rollout. I think many Intent to Ships go >>> through this sort of cautious rollout; they just don't necessarily discuss >>> the details of it on blink-dev. >>> >>> 2024年3月5日(火) 5:19 Mike Taylor <mike...@chromium.org>: >>> >>>> My concern is going from 1% to 50% on stable - if something does go >>>> wrong, that's a _lot_ of folks who will experience it. Are you open to >>>> something smaller like 5%? If not, why not? >>>> >>>> thx >>>> On 2/29/24 12:34 AM, Zheda Chen wrote: >>>> >>>> The volume of data on Beta is too low to draw any conclusion. Although >>>> the experiment on 1% stable shows some promising result, the data are not >>>> enough and we'd like to gather more data via experiment on higher >>>> percentage of stable. >>>> After that, based on large volume of data, we can draw the conclusion >>>> and decide next step (whether to ship the feature). >>>> >>>> I contribute the idea and CL source code of this feature, Francois >>>> (fdoray@) is the main reviewer and the trial is planned by him. Let us >>>> know >>>> if you have any concerns and we can discuss with fdoray@ together. >>>> >>>> "Unimportant" frames means they are cross-origin, visible but use >>>> non-large proportion (<75%) of page's visible area and have not received a >>>> user gesture. All 3 conditions should be met. >>>> >>>> On Thursday, February 29, 2024 at 10:26:22 AM UTC+8 >>>> mike...@chromium.org wrote: >>>> >>>>> Could you say more why you would like to experiment on 50% of stable, >>>>> vs requesting permission to ship? That's quite a leap from 1% - and it >>>>> seems you already have results demonstrating performance improvements. >>>>> >>>>> Also, mind answering the question of specifying "unimportant frames"? >>>>> On 2/27/24 5:54 AM, Zheda Chen wrote: >>>>> >>>>> fdoray@ launched this trial since Nov 2023, at first canary/dev, and >>>>> then beta, 1% stable. The experiments show statistically improvements to >>>>> CPU time on navigation, page load time and input delay. >>>>> So we are requesting to experiment on 50% stable as next step. >>>>> >>>>> Actually the feature should be in origin trial stage now. But I don't >>>>> have the permission to add origin trial stage. I have to use dev trial >>>>> instead. Need some help from webstatus-request@ to grant me the >>>>> permission. >>>>> >>>>> On Tuesday, February 27, 2024 at 8:53:34 AM UTC+8 mike...@chromium.org >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> To clarify: is this intended to be an I2E, or a Developer Trial? >>>>>> According to https://chromestatus.com/feature/5106220399853568, it >>>>>> appears you are in the dev trial stage. But you mention stable >>>>>> experiment >>>>>> below... so perhaps that's a process mistake? >>>>>> >>>>>> Can you give more info on the experiment timelines and what stable >>>>>> percentages you are requesting permission to experiment on? >>>>>> >>>>>> On 2/22/24 2:30 AM, Zheda Chen wrote: >>>>>> >>>>>> Contact emails >>>>>> zheda...@intel.com, fdo...@chromium.org >>>>>> >>>>>> Specification >>>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html >>>>>> >>>>>> Summary >>>>>> >>>>>> Align wake ups of JavaScript timers for unimportant cross-origin >>>>>> frames. Currently, DOM timers <32ms are all opt-out from AlignWakeUps >>>>>> [1] >>>>>> due to performance concerns. This is very conservative and actually some >>>>>> unimportant frames are eligible to use JS timer alignment. WebKit uses >>>>>> the >>>>>> policy to align DOM timer of non-interacted cross origin frames to 30ms. >>>>>> This feature adds JavaScript timer wake up alignment for unimportant >>>>>> frames >>>>>> on foreground pages. Unimportant frames means they are cross origin, >>>>>> visible but have small proportion of page’s visible area, and have no >>>>>> user >>>>>> interaction. [1] >>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4589092 >>>>>> >>>>>> Do you have plans to specify this concept of "unimportant frames" >>>>>> somewhere? >>>>>> >>>>>> >>>>>> >>>>>> Blink component >>>>>> Blink>PerformanceAPIs>Timers >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3ETimers> >>>>>> >>>>>> TAG review >>>>>> None >>>>>> >>>>>> TAG review status >>>>>> >>>>>> Not applicable >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> *Gecko*: No signal >>>>>> >>>>>> *WebKit*: No signal >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> 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? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Goals for experimentationWe plan to experiment on stable to confirm >>>>>> whether we observe same performance improvement as on lower channels and >>>>>> similar power benefit as in the lab. We will decide whether this feature >>>>>> ships based on the experiment data. >>>>>> >>>>>> >>>>>> >>>>>> Ongoing technical constraints >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>> >>>>>> Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> No >>>>>> >>>>>> Flag name on chrome://flags >>>>>> None >>>>>> >>>>>> Finch feature name >>>>>> ThrottleUnimportantFrameTimers >>>>>> >>>>>> Requires code in //chrome? >>>>>> False >>>>>> >>>>>> Tracking bug >>>>>> https://issues.chromium.org/issues/40942028 >>>>>> >>>>>> Estimated milestones >>>>>> DevTrial on desktop >>>>>> 122 >>>>>> DevTrial on Android >>>>>> 122 >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5106220399853568 >>>>>> >>>>>> 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+...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%40chromium.org >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%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+...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1996ccec-101e-4738-99d9-56855c8d33ec%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1996ccec-101e-4738-99d9-56855c8d33ec%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/730e3141-f81a-42b7-abd4-15297e23d607n%40chromium.org.
