Design Review: Prioritized Task Scheduling (big picture)

[shaseley]

こんにちは TAG-さん!

I'm requesting a TAG review of Prioritized Task Scheduling (big picture).

Scheduling is an important tool for improving website performance and user experience, particularly on interactive pages with a lot of JavaScript. Two important aspects of this are:

1. Yielding, or breaking up long tasks. Long tasks limit scheduling opportunities because JS tasks are not preemptable. Long tasks can block handling input or updating the UI in response to input, which is often a cause of poor responsiveness.
2. Prioritization, or running the most important work first. The (task/event loop) scheduler determines which task runs next on the event loop. Running higher priority work sooner can improve user experience by minimizing user-perceived latency of the associated user interaction.

The proposal consists of:

• a small number of semantic priorities, which are used to prioritize tasks and continuations, and are used by UAs to prioritize these tasks within the event loop
• several new APIs for scheduling and breaking up JavaScript tasks, with an associated priority
• modifications to a few existing async APIs to support prioritization

---

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md
• Specification: https://wicg.github.io/scheduling-apis/ (this covers scheduler.postTask(), scheduler.yield(), TaskController, and TaskSignal. Other APIs in the explainer are at earlier stages of thought/design).
• User research: N/A
• Security and Privacy self-review²:
  • postTask(): https://github.com/WICG/scheduling-apis/blob/main/explainers/security-privacy-questionnaire-post-task.md
  • TaskSignal.any(): https://github.com/shaseley/abort-signal-any/blob/main/tag-questionnaire.md
  • yield(): https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy
• GitHub repo: https://github.com/WICG/scheduling-apis/
• Primary contacts (and their relationship to the specification):
  • Scott Haseley (@shaseley), Google (feature/spec author)
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • scheduler.postTask(): https://chromestatus.com/feature/6031161734201344
  • TaskSignal.any(): https://chromestatus.com/feature/5202879349522432
  • scheduler.yield(): https://chromestatus.com/feature/6266249336586240

Further details:

• [X ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-implementer review or discussion of this design:
• Major unresolved issues with or opposition to this design:
• This work is being funded by: Google

You should also know that...

This review request is in response to a request for a "bigger picture" Scheduling APIs explainer (cc: @hober @plinss), and there is overlap with scheduler.yield()'s specification review in https://github.com/w3ctag/design-reviews/issues/966. Some of the work here (TaskController, TaskSignal (except .any()), and scheduler.postTask()) was reviewed in https://github.com/w3ctag/design-reviews/issues/647.

[martinthomson]

Thanks for doing this work. We see three general threads to this work, each of which are at a different stage, but all of which are worthwhile.

1. The work around basic task scheduling APIs, (yield and wait or whatever those end up being called). This is good stuff. We'd encourage you to take this to WHATWG and get that into their process now. Aside from maybe that open naming issue, it is pretty solid.

2. The work around render and requestAnimationFrame, which deals with how the event loop interacts with the rendering process. That seems less well formed, but still quite important, perhaps even more important than the first item. Having a firm understanding of that interaction and clear means of controlling it would be a significant contribution to stability and performance of sites. We'd encourage you to continue that work to understand that. Please, don't feel constrained by how requestAnimationFrame is; if there are ways in which that could be improved and integrated into a more comprehensive scheduling system, that would be excellent.

3. A general set of hooks that other APIs might use for scheduling work on the main event loop. To give an analogy, Fetch has an API for fetching stuff, but it also has a bunch of hooks that any other API can use if they need to obtain connections or resources. That's a useful contribution here also. For message channels or Fetch or WebRTC or whatever, the ability to schedule and prioritize work will be very useful. That aspect too needs work, but that can be taken to WHATWG also.