Intent to Extend Origin Trial: scheduler.postTask

91 views
Skip to first unread message

Scott Haseley

unread,
Sep 28, 2020, 6:29:00 PM9/28/20
to blink-dev

Contact emails

shas...@chromium.org, jap...@chromium.org


Explainer

https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md


Specification

None


Notes:

  1. Please note the spec requirement wasn’t yet in place for the original I2E, but the explainer is detailed with regard to the API details, including how the priorities work and will be specified.

  2. This might fall into the category of “early experimentation”, where we expect some iteration based on partner feedback (more below). We hope to start working on a proper spec soon, but we’ve put that on hold since we’re not entirely sure what will be included in V0, and OT feedback will likely help shape that.


Design docs

https://docs.google.com/document/d/1Apz-SD-pOagGeyWxIpgOi0ARNkrCrELhPdm18eeu9tw/edit?usp=sharing


Summary

Userspace tasks often have varying degrees of importance (related to user experience), but the Platform lacks a unified API to schedule prioritized work. The postTask API allows developers to schedule tasks (javascript callbacks) with a native browser scheduler at 3 levels of priority: user-blocking, user-visible, and background. It also exposes a TaskController, which can be used to dynamically cancel tasks and change their priority.


Blink component

Blink>Scheduling


Search tags

scheduling, scheduler, main thread, main-thread


TAG review

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


TAG review status

Pending


Risks


Interoperability and Compatibility

If other browsers do not implement the APIs, the situation is no worse than today; it will be possible to feature detect and take advantage of improved scheduling on browsers that do ship the API. This API was recently discussed at the WebPerfWG F2F (https://docs.google.com/document/d/1uQ7pXwuBv-1jitYou7TALJxV0tllXLxTyEjA2n1mSzY/edit?ts=5d0774e5#heading=h.ptau5ck3jdlk). The overall sentiment was positive, especially from developers present at the meeting. Browser vendors appear generally cautious, but supportive.


Gecko: No signal


WebKit: No signal Priority inversion and dependency tracking are concerns. We plan to flesh these concerns out and address them as the API progresses.


Web developers: Strongly positive Positive feedback at WebPerf WG F2F (https://docs.google.com/document/d/1uQ7pXwuBv-1jitYou7TALJxV0tllXLxTyEjA2n1mSzY/edit?ts=5d0774e5#heading=h.ptau5ck3jdlk). We are also closely working with React and Airbnb, who are strongly positive about the API.


Ergonomics

Could the default usage of this API make it hard for Chrome to maintain good performance? Unlikely. There is always concern around starvation and abuse when introducing (higher) priorities. But it is always a possibility that script just won't yield (or queue microtasks, or abuse rAF) -- which are as high or higher than priorities we are planning to introduce. We will continue, however, to think about abuse and mitigation as we develop the API.


Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is? No. Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use? Yes.


Security

https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md#security-considerations



Goals for experimentation

API shape

  - We want to validate that the new Signal/Controller-based API is ergonomic for developers (the shape has evolved quite a bit). Is it easy to use/integrate with existing schedulers or app code?

  - We also want feedback on the priorities: are the priorities intuitive/useful? Are there (general) use cases that aren’t captured by these priorities? (See explainer for more discussion around number of priorities).


Performance: We’re relying on site-specific latency and responsiveness metrics for measuring performance. Specifically, we’re looking to find out if site-specific performance improves, regresses, or stays the same. The outcome can depend on a lot of factors, e.g. does the site already have a scheduler? how much of the page does the site own? how well does the implementation’s approach to integrating postTask tasks and tasks from other task sources work? Our hypothesis is that performance shouldn’t regress, but we want to validate this. And if it does regress performance, we want to understand why and possibly vary the implementation.


Usefulness of the MVP: We’re looking to answer a couple questions here:

  1. Does the API simplify scheduling?

  2. Is the postTask MVP useful enough on its own, or are there vital features missing? For example, are there enough guarantees/predictability around postTask priorities to be useful, or are priorities needed elsewhere (e.g. fetch, IDB)?


Experimental timeline

M86 -- M87


Further rationale and notes:

  - We have partners ready to experiment immediately and soon (see below). Given this current engagement, we’d like to continue experimenting now

  - Please note that the OT wasn’t enabled in M85 (we are aware of the burn-in risk)

  - We will likely need to extend the OT again once we integrate partner feedback. Our alternative plan was to extend the OT for 3 milestones now, but given the branch point for targeting M88 is Nov. 12, we don’t feel that would be enough time to incorporate feedback. We’re calling this out here since that could potentially take us over 6 total milestones, albeit with gaps.


Reason this experiment is being extended

Previous I2E: https://groups.google.com/a/chromium.org/g/blink-dev/c/31qZ-bMToM8/m/k1BefOpMAwAJ


We were unable to achieve our experimentation goals in the first OT, largely due to COVID-related partner delays. Our initial OT also only ran for 2 milestones since M82 was skipped. We have one partner that would like to continue experimenting immediately (React / Facebook -- they turned down the experiment after it exposed an internal bug, and are ready to resume), and one that wants to start in this new timeframe (Airbnb).


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

No


But it’s fully tested by Chromium wpt_internal tests: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/wpt_internal/scheduler/


Tracking bug

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


Launch bug

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


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6031161734201344


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/HvqbB7TGJKU/m/Kd0WUGXkAQAJ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/31qZ-bMToM8/m/k1BefOpMAwAJ



This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Oct 1, 2020, 4:17:01 AM10/1/20
to Scott Haseley, blink-dev
LGTM to experiment M86-87

From my perspective, since the OT was off for M85, we can "restart the clock" in M86.

--
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/CAKXGoJ0ykkHAfgBeavBBNvtL48WpWpSaP665koOa08R4ODFkkw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages