[w3ctag/design-reviews] Design Review: Prioritized Task Scheduling (big picture) (Issue #967)

こんにちは 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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop#run-to-completion). 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](https://www.w3.org/TR/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](https://github.com/w3ctag/design-reviews/issues/827) 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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/967
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/967@github.com>