How do we measure the effectiveness of this API? about scheduling-apis

[gvergnaud]

Hey!

For the sake of giving an additional data point, here is how we use the scheduler API at @DataDog.

We use this new API and its polyfill pretty extensively. We've seen significant perf improvements on our dashboards by splitting long rendering tasks into one task per "widget". We assign either a "user-visible" or a "background" priority based on whether they're in the viewport or not, which means we have to update theses priorities as users scroll the page. We are pretty happy with the ergonomics of this new scheduler API, which makes updating a task's priority over time very easy!

This experiment has been very successful and we would like to keep using this API, so let us know if we can support its standardization in any way! I just tested the Firefox Nightly implementation and it works like a charm.

I'd be pretty interested in trying to use scheduler.yield in our functions processing large amounts of data to avoid blocking the main thread for too long when this API becomes available.

Let me know if you have specific questions about our use case, I'd be happy to help in any way 🙂

[shaseley]

Hi @sefeng211, Airbnb wrote a blog post about how they used postTask on their site, which might be helpful.

cc @calinoracation (Airbnb) who wrote the post and worked with us while developing the API.

[calinoracation]

Hi @shaseley & @sefeng211.

We are using postTask extensively at this point. We associate most of our UI event handlers that have to do with an intersection observer triggering or a window resize with postTask and choose a priority based on whether we will impact the current screen. This still gives us really nice scheduling compared to a nextTask or requestIdleCallback scenario in being able to schedule more things while avoiding most long tasks.

The other nice thing is the API is unified, folks don't need to think about using setTimeout(, 0) vs requestIdleCallback vs Promise.then(). They just choose a priority.

We also added on additional capabilities to our React wrapper that let's us implement a recycle pattern, so that window resize example can have a delay of 50ms and each call would call abort() before postTask and get a really easy debounce pattern. We use that for other optimizations like setting a scrolling element to be scrollable or fixed for reducing layers on mobile web, but only after it has been in view for a certain amount of time.

We always have more work to do, but postTask is now a really highly used tool that many of our folks have adopted and gotten really nice gains from.

[sefeng211]

cc @bdekoz @shaseley

[sefeng211]

Thanks @calinoracation , That was a good read and very helpful!

[smaug----]

Does anyone know other users of the API? Or is there any new feedback from Airbnb? The API itself doesn't really add new primitives to the platform, so everything could be implemented using a polyfill.
We at Mozilla are still pondering what to do with the API.

There are some unclear parts of the API, like how TaskPriority actually should affect to scheduling vs other tasks which aren't using postTask. API users might think "background" for example is something similar to idle handling, but that is not how it is specified. Or that "user-blocking" tasks get run before user input or visual updates, but that isn't how it is defined either.

[sefeng211]

## Native scheduling API
Interested partners: React, Ember, Airbnb.

@shaseley do we know the status of React and Ember? are they still interested in this API?

[shaseley]

I'm not sure about Ember - I think that was before I was involved on this.

The last I spoke with React, they were thinking it would make more sense for them to use it in conjunction with scheduler.yield(), so they aren't using it yet AFAIK, although they did run an Origin Trial on Facebook when we were designing the API. @acdlite can correct me if I'm wrong about any of that :). One thing I've been wondering for React's case is if there would be any noticeable improvement from avoiding the overhead of MessageChannel (I think there are IPC hops even for same-window case in Chrome. /cc @yoavweiss ).

Datadog started using it recently for their dashboards, and @gvergnaud might be able to comment further.

I suspect we'll start see more usage as we work with sites on improving Interaction-to-Next-Paint (INP), because scheduling plays a big role there. Long tasks negatively affect responsiveness, so breaking them up is key. You can do that by scheduling smaller bits (i.e. use postTask() or similar), or by periodically yielding (I'm working on prototyping scheduler.yield() now. We've heard from some folks that using these together would ideal.

@smaug---- regarding prioritization semantics, you're right that a lot of the behavior is left up to the UA. This was intentional because there was initially concern (I think from Boris on the initial TAG review) about creating a total ordering of priorities and limiting a UA's ability to experiment with prioritization between different task types. I agree that we wouldn't want to do that, so I left things largely up to the UA (but well-defined for postTask-tasks). I'd be open to discussing this more (maybe at WebPerfWG?)!

In Chrome, the priority of "background" is similar to requestIdleCallback, but we don't wait for an idle period to run them (they just have lower priority than most other things). "user-blocking" is implemented as a higher priority than most other JS-visible tasks (timers, postMessage, fetch, etc.), but lower priority than input (this is highest for us), and these tasks won't indefinitely starve rendering. So using this priority allows an app to stay responsive to input/rendering updates, but doesn't let a lot else through (which depending on how the site is architected, might matter a lot for performance, e.g. rendering main viewport contents first).

The other thing is that if priorities are to be meaningful across a page (e.g. between a framework and 1P, library and 1P, etc.), the scheduler needs to be centralized. The browser is the natural place to do this, otherwise everything needs to use the same polyfill.

[smaug----]

Since input aligns with rAF, and there is plenty of time between rAFs, can "user-blocking" tasks run before input? Because of rAF alignment, input priority is kind of special in Firefox at least, or rather, it is special when rAF is ticking at all.

Having "background" meaning lower priority than most others is a major thing. That is a new feature to the platform, but the spec doesn't really define that. And how does "user-blocking" actually work in Chrome? Is it higher priority than vsync/raf ? Nothing of this is defined in the spec, yet would/has lead to incompatible implementations.

It feels like the spec should be a bit more descriptive on the priorities and how it is supposed to work with other tasks not defined in this spec. (I know, priorities are hard. We want to keep the flexibility to reorder things when needed, yet some hints how things are supposed to behave would be good.)