Intent to Ship: scheduler.yield()

935 views
Skip to first unread message

Scott Haseley

unread,
Aug 9, 2024, 5:19:57 PMAug 9
to blink-dev

Contact emails

shas...@chromium.org

Explainer

https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md
https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md#scheduleryield

Note: The explainer includes parameters to yield(), but we're initially shipping this with only the default behavior described in the specification. It wasn't clear if the parameters were necessary, there was some concern internally over the exact behavior, and it complicates the API. They may yet prove necessary, but it's safer to roll this out --- handling the main use case --- and revisit later, if needed.

Specification

https://wicg.github.io/scheduling-apis/#dom-scheduler-yield

Summary

Provides a method for yielding control to the browser, which can be used to break up long tasks. Awaiting the promise returned by scheduler.yield() causes the current task to yield, continuing in a new browser task. This can be used to improve responsiveness issues caused by long tasks. Continuations are prioritized to mitigate performance problems of existing alternatives.



Blink component

Blink>Scheduling>APIs

TAG review

https://github.com/w3ctag/design-reviews/issues/966

TAG review status

Pending

Chromium Trial Name

SchedulerYield

Link to origin trial feedback summary

https://docs.google.com/document/d/1HSlhqWsamWyR9bwgtCzB2TpVW7CUm9QkyKbK0TdM0RA/edit?usp=sharing

Origin Trial documentation link

https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md

Risks



Interoperability and Compatibility

This is a new feature and will not change existing event loop task scheduling, so the main risk is that other browsers might not implement the feature. There is an interop challenge, however, that comes with prioritization: we want to be specific enough to provide developers guarantees and interoperable implementations, but provide enough scheduling flexibility for UAs (like the HTML specification does with task sources/task queues), which we'll keep in mind while drafting the spec (see also https://github.com/WICG/scheduling-apis/issues/67).



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1039) Note that the issue opened for yield() was folded in with the original Scheduling APIs proposal, as this is an enhancement to that.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/361)

Web developers: Positive

Several partners were able to improve site performance using the API during Origin Trial (see the Origin Trial feedback link for quotes).

Also some tweets I found with positive sentiment:
 - https://x.com/sebastienlorber/status/1589939130225475584

Other signals:

Ergonomics

The default use (inserting yield points in long tasks) should enable Chrome to maintain better performance (responsiveness). There is a risk of continuations starving other work, but there are reasonable mitigations, e.g. bounding total of prioritized continuations (see also https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#preventing-task-starvation-by-continuations).



Activation

The feature would benefit from a polyfill so that tasks still yield in the case the feature is unavailable. The behavior can be approximated by awaiting `scheduler.postTask()` or wrapping `setTimeout(0)` in a promise. The signal inheritance bit [1], however, would need transpilation support to propagate the current signal across async (Promise) boundaries.


[1] https://docs.google.com/document/d/1rIOBBbkLh3w79hBrJ2IrZWmo5tzkVFc0spJHPE8iP-E/edit#heading=h.c484rp62uh2i

Security

https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy https://wicg.github.io/scheduling-apis/#sec-security



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 is a new API.



Debuggability

This has basic new-API devtools support. We plan to work with the devtools team to see if we can integrate continuations into the performance panel in some way.



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

https://wpt.fyi/results/scheduler/tentative/yield?label=experimental&label=master&aligned



DevTrial instructions

https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md

Flag name on chrome://flags

--enable-blink-features=SchedulerYield

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=979020

Measurement

Usage is measured by the SchedulerYield UseCounter: https://chromestatus.com/metrics/feature/popularity#SchedulerYield

Availability expectation

Initially available only in Chromium browsers.

Adoption expectation

Feature is a key part of optimizing long tasks, which contribute to poor responsiveness: https://web.dev/articles/optimize-long-tasks. Several partners are waiting for this API as part of INP optimization efforts.

Adoption plan

There has already communication with developers in anticipation of this API, e.g. https://web.dev/articles/optimize-long-tasks. I'll work with the devrel team on what additional communication may be required.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No.

Estimated milestones

Shipping on desktop129
Origin trial desktop first115
Origin trial desktop last120
DevTrial on desktop113
Shipping on Android129
Origin trial Android first115
Origin trial Android last120
DevTrial on Android113
Shipping on WebView129
Origin trial WebView first115
Origin trial WebView last120


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


No breaking changes are expected, but enhancements may be added as we learn more from usage. We also may need to adjust our internal scheduling policies (i.e. relative ordering of task sources) depending on what we learn from early adopters.

The open issue that could potentially affect this API is the naming of related "yieldy" APIs: https://github.com/WICG/scheduling-apis/issues/95. This was raised in the WebKit position, specifically that scheduler.render() (future API enhancement) doesn't quite fit. We plan to name around scheduler.yield(), and are leaning towards rolling scheduler.render() in as a yield() parameter -- but this is still TBD.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6266249336586240?gate=6275382550986752

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1SBQP-ABM3%2BsDtKzUZiPoSCWqW2mLOjMrUfFBx4TomSw%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1Uj8nX5HrUT86iZ83YBj%3D6GJ4jnKZKYF3tOq%3D_twN_Yg%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Domenic Denicola

unread,
Aug 15, 2024, 12:36:04 AMAug 15
to Scott Haseley, blink-dev
Very exciting to see this ready to ship after what sounds like a successful experiment. A few small questions...

I think this should be no chrome://flags, and a Finch feature name of SchedulerYield. (Assuming you got the default of having a base::Feature generated from the Blink feature.)
https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#open-questions lists a few open questions, which could have compat impacts. I suspect that section of the explainer just hasn't been updated. Can you confirm?
 
--
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/CAKXGoJ3q%2BzPuSwBQ6Xp48aCP6m1kdE30Znh4wuzB_bL16UQwBg%40mail.gmail.com.

Scott Haseley

unread,
Aug 15, 2024, 11:33:55 AMAug 15
to Domenic Denicola, blink-dev
Ah, right. I did the default thing in runtime_enabled_features, so the Finch feature name would be SchedulerYield. I think the chrome://flags thing was left over from needing to provide the flag for dev trial. Updated in chromestatus.
Confirmed. The outcome of those:

>> 1. What should the default option be, inheritance or 'user-visible' priority?

The API inherits the originating task's priority/signal if it was scheduled with scheduler.postTask() or requestIdleCallback ("background" priority continuation).

>> 2. Does yield({priority}) set the priority to be inherited in future calls, or is the original signal used?

This is what I mentioned in the explainer section. We removed the parameters (for now), so this no longer applies, but we'll have to revisit this if reinstating the parameters.

>> 3. Should the API be allowed to return a resolved promise, if it knows it won't run other work? This could be more trouble than it's worth, but maybe there's potential to cut down (scheduling) overhead.

We didn't end up pursuing this.

Domenic Denicola

unread,
Aug 15, 2024, 10:45:03 PMAug 15
to Scott Haseley, Domenic Denicola, blink-dev
LGTM1!

Please consider updating the explainer a bit to capture where things ended up, or at least adding a warning of some sort that it's a bit out of date.

Daniel Bratell

unread,
Aug 21, 2024, 12:06:12 PMAug 21
to Domenic Denicola, Scott Haseley, blink-dev

LGTM2

/Daniel

Alex Russell

unread,
Aug 21, 2024, 1:20:05 PMAug 21
to blink-dev, Daniel Bratell, blink-dev, Domenic Denicola, Scott Haseley
LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.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+unsubscribe@chromium.org.

Scott Haseley

unread,
Aug 23, 2024, 6:22:29 PMAug 23
to Alex Russell, blink-dev, Daniel Bratell, Domenic Denicola
Thanks all!

This will be enabled in M129. (Note: this just missed the M129 branch, so it wasn't in the initial Chrome Beta release --- but has since been merged, so it should be in Beta soon.)

On Wed, Aug 21, 2024 at 10:20 AM Alex Russell <sligh...@chromium.org> wrote:
LGTM3

On Wednesday, August 21, 2024 at 9:06:12 AM UTC-7 Daniel Bratell wrote:

LGTM2

/Daniel

On 2024-08-16 04:44, Domenic Denicola wrote:
LGTM1!

Please consider updating the explainer a bit to capture where things ended up, or at least adding a warning of some sort that it's a bit out of date.

I will, thanks for suggesting.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.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.

Yoav Weiss (@Shopify)

unread,
Aug 28, 2024, 6:29:06 AMAug 28
to Scott Haseley, Alex Russell, blink-dev, Daniel Bratell, Domenic Denicola
I was out while this thread happened, but just wanted to chime in and say I'm super excited for this shipping!!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3pjM264fK9exzEKK6p347oLUrp-1-4wC79ZSYO5BeGAA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages