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.

Motivation

It is too difficult to build web apps that are responsive to user interaction and remain responsive over time. Script is a primary culprit that hurts responsiveness (https://tdresser.github.io/input-latency-deep-reports/). Consider a "search-as-you-type" application: this app needs to be responsive to user input i.e. user typing in the search-box. At the same time any animations on the page must be rendered smoothly, as well as the work for fetching, preparing and displaying search results must progress quickly. Scheduling can be an important tool for improving site performance and user experience. By breaking up long tasks into smaller tasks (or chunks), the page remains responsive if the app yields to the event loop between tasks. Running high priority work sooner can improve user experience by minimizing user-perceived latency of the associated interaction. Userspace schedulers exist for this purpose, and use priority to order execution of their tasks. But this priority has limited meaning since they do not control all tasks on the page. The lack of a first-class scheduling API has disadvantages: - The browser is unaware of app priorities, limited how it can prioritize internally - There isn’t a coherent notion of priority across a page - The lack of a unified scheduling API is onerous on developers, making it even more complicated to write scheduling code - The primitives we do have don't support key features like dynamic prioritization

Specification

Public discussion

Status in Chromium

Blink>Scheduling


In developer trial (Behind a flag) (tracking bug) in:

  • Chrome for desktop release 94
  • Chrome for Android release 94
  • Android WebView release 94

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

Owners

Intent to Prototype url

Intent to Prototype thread

Comments

- We're waiting on the TAG spec review, but the pre-spec TAG review is here: https://github.com/w3ctag/design-reviews/issues/338 - https://github.com/WICG/scheduling-apis/issues/26 will be addressed prior to shipping, we're just waiting on TAG input (I've just requested this outside of our TAG review). - One important open issue is https://github.com/WICG/scheduling-apis/issues/24, which is that isInputPending is on navigator.scheduling and we specced postTask on window.scheduler. Our plan is to move isInputPending to window.scheduler after postTask ships. We would alias navigator.scheduling.isInputPending to window.scheduler, update the isInputPending spec, and begin the deprecation process.

Search tags

scheduling, scheduler, main thread, main-thread,

Last updated on 2021-07-30