Prioritized Task Scheduling

[shaseley]

WebKittens

@annevk @hober

Title of the spec

Prioritized Task Scheduling

URL to the spec

https://wicg.github.io/scheduling-apis/

URL to the spec's repository

https://github.com/wicg/scheduling-apis/

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md

TAG Design Review URL

w3ctag/design-reviews#967

Mozilla standards-positions issue URL

mozilla/standards-positions#1039

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This proposal is for a suite of prioritized task scheduling APIs, which enable developers to break up and schedule work to improve user experience while having some control and influence over task ordering. The individual APIs in the linked explainer are in various stages of development.

For the APIs in the specification, which is the main focus of this request:

• scheduler.postTask(), TaskController, and TaskSignal:
  • Position originally requested in https://lists.webkit.org/pipermail/webkit-dev/2021-June/031912.html
  • Shipped in Chromium in M94 (2021)
  • Original TAG review: scheduler.postTask() w3ctag/design-reviews#647
  • Note: TaskSignal has since been updated with a specialization of AbortSignal.any(), which is also included in the spec and explainer
• scheduler.yield()
  • TAG early design review: Early design review: scheduler.yield() w3ctag/design-reviews#827
  • TAG spec review: Spec review for scheduler.yield() w3ctag/design-reviews#966
  • Note: this is active work, which we're hoping to ship in Chromium soon

The other ideas in the linked explainer — which build on the same primitives/ideas — are less fleshed out, but hopefully help to understand the broader picture. We've also filed a TAG design review for the overall Prioritized Task Scheduling work in w3ctag/design-reviews#967.

[annevk]

Curious if there are other posts similar to https://medium.com/airbnb-engineering/building-a-faster-web-experience-with-the-posttask-scheduler-276b83454e91 about adoption of the API. In particular I think the point of splitting up "long tasks" is compelling, but has there been interest in the more granular API surface such as changing priorities of a task that is in-flight? And will that additional complexity actually lead to meaningful improvements in performance? (It will also increase the amount of script that needs to be written and transferred.)

[shaseley]

I don't know of any posts or articles discussing dynamic prioritization. It was something that came up with partners initially when designing the API, e.g. to dynamically reprioritize tasks during loading as the viewport changes (IIRC Datadog might be doing something like this). But usage of TaskSignal.setPriority() is much lower than that of scheduler.postTask(). There has been more focus on scheduling recently, however, due to a recent focus on interaction-to-next-paint, so we might see usage of that tick up -- although I'd imagine not in the common case.

[annevk]

One other thing that came up when looking at this internally is that yield() and render() are inconsistently named. (And yield() is probably the odd one out given wait() and postTask().)

With await scheduler.render() you're awaiting rendering to happen. But with await scheduler.yield() you're not waiting for yield to happen. You're waiting for a continuation task.

[shaseley]

I had thought the naming was consistent, since in each case you're waiting for a task to run after the associated action (the continuation always happens in a new task, not during the action):

API	Action to resume after	Behavior
scheduler.yield()	yield to the event loop	The returned promise is resolved in a new task (after yielding to the event loop, which is implied by a new task), allowing higher priority work to run
scheduler.wait()	X ms have elapsed	The returned promise is resolved in a new task after the X ms
scheduler.render()	rendering	The returned promise is resolved in a new task after rendering

We're open to renaming yield() if there's a better name, but we haven't thought of one. And I think "yielding" as a strategy for responsiveness is common enough that it's a good name for the API (some motivation for the current name is mentioned here). We discussed maybe prefixing these with after to help alleviate confusion, but I'm not sure if that's worth it.

[annevk]

I discussed this some more with colleagues and the concern is that if you think of each of the names as describing what it waits for and what it does, they are not consistent:

• yield: describes what it does, but not what you wait for
• wait: describes what it does and arguably what you wait for (the argument)
• render: does not describe what it does, but does describe what you wait for

You could possibly make these names more aligned by renaming render to waitForRender or yield to currentTask. What do you think?

[shaseley]

Thanks @annevk, I agree with your assessment. I'm still thinking about this -- I filed WICG/scheduling-apis#95 with some additional naming concerns that came up in discussions and to solicit wider feedback. I'm not opposed to waitForRender(), but wondering if switching to noun names would be better (it's growing on me).