Intent to Extend Origin Trial: scheduler.postTask

[Scott Haseley]

Contact emails

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

Explainer

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

Specification

None

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

Edge: 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, Google Maps, 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

M88 -- M89

(Previous OT was M86 -- M87)

Reason this experiment is being extended

A partner (Airbnb) is requesting that we extend the OT so they can start  a new experiment after fixing a data imbalance issue.

Previous I2E: https://groups.google.com/a/chromium.org/g/blink-dev/c/6KrwUguadyE/m/GK5C8KbWCQAJ

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://www.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/6KrwUguadyE/m/GK5C8KbWCQAJ

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

LGTM to extend to M89.

Could you also comment on what feedback from the OT has been received so far?

--
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/CAKXGoJ1jW8zLkMkBtOwEHBQjf_c5ukPGdK%2B7Tn5ghHPanmy7Ug%40mail.gmail.com.

[Scott Haseley]

Hi Chris,

I'm forwarding along some feedback from Airbnb. For context, they've been experimenting using postTask to break up/defer work with a goal of improving responsiveness and loading metrics.

+Callie Riggins 

Metrics:
They're re-running the experiments to get more accurate numbers, so I’ll just give a high-level assessment rather than raw numbers.
 - Improvements to several responsiveness metrics: TBT, FID, long input delays
 - Improvements in FCP on a couple pages
 - Regression in FCP on another, primarily SSR’d page

When asked about functionality/ergonomics:

“I'm hoping the next experiment proves that out more. I think both myself and Josh really like the API and think it is helpful, once we get it out of this ERF we can open it up to more folks and get more feedback from our entire FE community”

Other feedback:

“Primary high level comments/feedback on the API is similar to what we talked about before, that the custom delay is very useful. Also that w/out async/await, the API is much more challenging to nest, but that's likely not an issue for most folks using this. The TaskQueue abstraction we built to inherit signals was useful when grouping some tasks, but ultimately might of been less beneficial than anticipated. Using the abort signal came with some unexpected issues around GraphQL caching where we would cancel the fetch of a prefetch but then the caching layer didn't realize that and never returned, but again specifically an issue with our GraphQL client.

The custom delays we built were the nicest sugar on top of the main API.

Primary issues on education is for folks to understand when to reach for one of these vs something like an rAF or rIC (the latter of which I've replaced primarily w/ background priority)”

For more info on the feedback about custom delays (i.e. tying tasks to events), see this github issue.