Intent to Experiment: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

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

Blink component

Blink>PerformanceAPIs>Timers

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 experimentation

We 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?

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.

[Mike Taylor]

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

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?

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.

--
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.

[Zheda Chen]

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.

[Mike Taylor]

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"?

[Zheda Chen]

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.

[Mike Taylor]

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

[Domenic Denicola]

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>:

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.

[Etienne Pierre-doray]

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'.

[Domenic Denicola]

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?

[Zheda Chen]

Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

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 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

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?
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.

[Zheda Chen]

Okay I update the process stage in Chrome Platform Status, and paste the newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568

[Domenic Denicola]

Can you fill out the interoperability and compatibility risks section here? I don't think standards position requests are necessary, but saying how this behavior might break existing sites that assume Chromium's current behavior, and how this new behavior compares to WebKit and Gecko, would be helpful.

Also, can you request the privacy/security/enterprise/debuggability/testing gates on Chrome Status?

[Daniel Bratell]

This intent has ended up in a strange state in the chromestatus tool, missing various flags I would have expected. Is that because the intent predates some of the chromestatus updates or because it started as an origin trial? If so, maybe the simplest is to refile it, or can it be made to be a proper Intent to Ship with all the buttons and bullets?

Another few things though, and I hope I'm not repeating something already covered elsewhere.

First, I really like the idea of doing optimizations that have a measurable impact on user behaviour and probably also power usage and energy usage so I approve of this work. But then I have questions.

The text mentions that WebKit uses an alignment on 30 milliseconds intervals, but what is the intention for Chromium? Also 30 milliseconds?

If the idea is for it to be 30 milliseconds, that would be too sparse to allow 60 fps animations run on setTimeout. If so, is that intentional, and would that be acceptable?

I ask in particular, because "uninteresting iframe" is vaguely defined so I don't know how much content will be misclassified as "uninteresting".

In general, is the answer to my questions above covered by some specification we can point people to when they wonder why something behaves inexplicably?

/Daniel

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

[Daniel Bratell]

One more question, is requestAnimationFrame affected at all or will that still work just as before?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/84ea7a78-d9e2-40d2-adf7-3185f4d2a2d9%40gmail.com.

[Zheda Chen]

More details are updated in ChromeStatus, including interoperability and compatibility risks, Safari/Firefox views, web platform tests. It compares the behaviors across different browser vendors. 
https://chromestatus.com/feature/5106220399853568

Will send the updated "intent to ship" to this thread later if it looks good.

AFAIK, I don't see potential privacy/security issues, so can i set "security review status" and "privacy review status" to "not applicable"? Please let us know if you have any concerns.

[Zheda Chen]

Yes the intent started as an origin trial, now more details and bullets are added in ChromeStatus and I'm about to send "intent to ship".

As for your question about "alignment interval", the alignment interval for Chromium would be 32ms. The specification mentions "the SetTimeout/SetInterval API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected. The wait length of time is implementation-defined, which is intended to allow user agents to pad timeouts as needed to optimize the power usage of the device".

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

Actually, different browser vendors do have different implementation about the wait length of time. Webkit would align DOM timer of non-interacted cross origin frames to 30ms, while in Gecko, all DOM timers of frames (both same origin and cross origin) are aligned to 16ms. So web developers cannot expect the delay is the same across user agents. I already put this note to "interoperability and compatibility risks" of the feature in ChromeStatus.

If the work is related to animation, then requestAnimationFrame is much better at scheduling animation work than JavaScript timers. It synchronizes with the refresh rate of the device, ensuring you only get one callback per displayable frame, and you get the maximum amount of time to construct that frame. requestAnimationFrame would not be affected.

https://developer.chrome.com/blog/timer-throttling-in-chrome-88#animation

[Mike Taylor]

The privacy and security teams review all intents, so requesting reviews and answering the relevant questionnaires is the best path forward.

Looking forward to the new I2S - thanks!

[Zheda Chen]

Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

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 non-large proportion of page’s visible area, and have no user interaction. The alignment interval is 32ms. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4589092

Blink component
Blink>PerformanceAPIs>Timers

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

"Other vendors already have interoperable implementation" Safari has a similar intervention. DOM timers of non-interacted cross origin frames are aligned to 30ms. In Firefox, all DOM timers (both same-origin and cross-origin) in foreground pages would be aligned to 16ms. "A mature specification in the relevant standards body" This intervention is spec-compliant. The spec mentions "the SetTimeout/SetInterval API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected. ". The wait length of time is implementation-defined, "which is intended to allow user agents to pad timeouts as needed to optimize the power usage of the device. " https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html "A shared test suite for that specification" It isn't clear what should be tested specifically for this intervention since the spec allows waiting for an "implementation-defined" length.

Gecko: Shipped/Shipping
In Firefox, all DOM timers of frames (both same origin and cross origin) are aligned to 16ms

WebKit: Shipped/Shipping
In Safari, DOM timers of non-interacted cross origin frames are aligned to 30ms after reaching max nesting level (>=5)

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?

Yes

This intervention doesn't require changes to the spec. Timers are already covered by Web Platform Tests.

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Launch 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

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

You should be able to see all the various bits for approvals in your chromestatus entry now, can you fill them out please?

There have been a few questions/comments about the lack of clarity of what "unimportant cross-origin frames" are. What exactly is the definition? You mention that Safari has a similar intervention - how similar is it? Do we know? I wonder if there is alignment for this "unimportant cross-origin frame" concept, if we shouldn't specify that somehow.

[Zheda Chen]

The privacy/security/enterprise/debuggability gates are requested on Chrome Status. Testing gate to be requested later.

"Unimportant" cross origin 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. The criteria are too long so we use "unimportant" concept here.

This intervention is spec-compliant. The spec mentions "the SetTimeout/SetInterval API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected". The wait length of time is implementation-defined, "which is intended to allow user agents to pad timeouts as needed to optimize the power usage of the device". In Safari, DOM timers of non-interacted cross origin frames are aligned to 30ms after reaching max nesting level (>=5). In Firefox, all DOM timers of frames (both same origin and cross origin) are aligned to 16ms. See details in "Interoperability and Compatibility Risks", "Safari views", "Firefox views".

[Yoav Weiss (@Shopify)]

On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen <zheda...@intel.com> wrote:

The privacy/security/enterprise/debuggability gates are requested on Chrome Status. Testing gate to be requested later.

"Unimportant" cross origin 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. The criteria are too long so we use "unimportant" concept here.

This intervention is spec-compliant. The spec mentions "the SetTimeout/SetInterval API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected". The wait length of time is implementation-defined, "which is intended to allow user agents to pad timeouts as needed to optimize the power usage of the device". In Safari, DOM timers of non-interacted cross origin frames are aligned to 30ms after reaching max nesting level (>=5). In Firefox, all DOM timers of frames (both same origin and cross origin) are aligned to 16ms. See details in "Interoperability and Compatibility Risks", "Safari views", "Firefox views".

I believe the question Mike asked is not if this is spec compliant, but if the specifics of this should be more tightly specified, given that both WebKit and Chromium find a similar intervention useful.

 

--
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/7b8b9b84-2285-4fa9-a80d-c5fc0c1c0c41n%40chromium.org.

[Mike Taylor]

On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote:

On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen <zheda...@intel.com> wrote:

The privacy/security/enterprise/debuggability gates are requested on Chrome Status. Testing gate to be requested later.

Thanks - we've been asked to not send LGTMs until all bits have been requested. Can you let us know when Testing is?

"Unimportant" cross origin 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. The criteria are too long so we use "unimportant" concept here.

Thank you - that's much more clear to me now.

This intervention is spec-compliant. The spec mentions "the SetTimeout/SetInterval API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected". The wait length of time is implementation-defined, "which is intended to allow user agents to pad timeouts as needed to optimize the power usage of the device". In Safari, DOM timers of non-interacted cross origin frames are aligned to 30ms after reaching max nesting level (>=5). In Firefox, all DOM timers of frames (both same origin and cross origin) are aligned to 16ms. See details in "Interoperability and Compatibility Risks", "Safari views", "Firefox views".

I believe the question Mike asked is not if this is spec compliant, but if the specifics of this should be more tightly specified, given that both WebKit and Chromium find a similar intervention useful.

Right - that's my question. I also asked how similar this change is to whatever Safari implements - do they also align wakeups of JS timers for cross-origin, < 75% of viewport, frames that haven't yet received a user gesture? You previously wrote "non-interacted cross origin frames" for WebKit. Is there also a viewport condition?

[Etienne Pierre-doray]

Right - that's my question. I also asked how similar this change is to whatever Safari implements - do they also align wakeups of JS timers for cross-origin, < 75% of viewport, frames that haven't yet received a user gesture? You previously wrote "non-interacted cross origin frames" for WebKit. Is there also a viewport condition?

I don't think WebKit has a viewport condition. [code]

  

I believe the question Mike asked is not if this is spec compliant, but if the specifics of this should be more tightly specified, given that both WebKit and Chromium find a similar intervention useful.

Defining this concept in the spec would presumably be used to more strictly define when throttling is allowed (1) or mandatory (2) by browsers. I really don't think it's useful to specify this more tightly in the spec, as it makes performance interventions overly restrictive and is prone to rotting over time, as common patterns and APIs evolve.

1- Allowing throttling *only* for some definition of unimportant frames could provide a more predictable platform to web devs, but it seems overly restrictive on what the platform is allowed to do, and locks us in wrt. the kind of performance intervention we're allowed to do. This is already not true: both Webkit and blink implement various throttling in power-reducing situations other than unimportant frames.

2- It's unclear how making throttling mandatory in certain situations brings value to web devs, especially if the intervention is different among browsers. It does however add unnecessary constraints on the platform.

As a case in point, the spec specifies a mandatory 4ms delay on settimeout (8.6.5) with a nesting level greater than 5. This intervention doesn't really make sense in modern day browsers, and neither blink or webkit are spec compliant (in distinct ways).

[Mike Taylor]

Thank you for the answers Etienne. Once the Testing bit has been requested, I'm happy to give an LGTM.

[Yoav Weiss (@Shopify)]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Taylor]

LGTM2

[Domenic Denicola]

LGTM3.

With my HTML Standard editor hat on, I agree that this area does not benefit from tight specification.

However, in the past we've seen web developers be pretty confused by what each browser's behavior is, for this and other inactive-tab / offscreen-iframe / etc. throttling behaviors. Would it be possible to have some sort of document summarizing Chromium's timer throttling behavior? Probably the easiest would be in the source tree, but an evergreen article on developer.chrome.com or MDN would also be great. (This feedback is optional and does not block shipping.)

[Reilly Grant]

+1 to documenting Chromium's behavior in an evergreen format even if this isn't formally specified. I am constantly getting questions from developers about this and it is driving FUD about the capability of the web platform.

LGTM2

LGTM1

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/7b8b9b84-2285-4fa9-a80d-c5fc0c1c0c41n%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/20b3b7c6-780b-4715-9507-cd53cb5b1e29n%40chromium.org.