Tracking microtasks?

[nolanlawson]

Nice explainer! One thing I'm wondering, though, is whether it would also make sense to track microtasks. In the case of MutationObserver or Promises, it's possible to jank the main thread with 50 microtasks that each take 1ms, thus exceeding the 50ms threshold but not showing up as a "long task" because it was 50 separate operations. This would be a way for e.g. third-party ad networks to jank the main thread but still fly under the radar, undetected by the proposed API.

Obviously tracking microtasks would make it much more difficult to give proper attribution, but it seems like something worth considering. Even ignoring the possibility of bad actors trying to defeat the system, Promises are in pretty widespread use these days, so a lot of jank is happening that would go unmeasured if we didn't take microtasks into account.

[domenic]

Microtasks are a type of task, so they should fall under the same system as in this explainer.

It seems like your real concern is about people using a series of 1 ms tasks (including potentially microtasks) to defeat any long task detection? I'm not sure what could be done about that in general... they aren't exactly long tasks anymore.

[nolanlawson]

Yep, that was my question. Keep in mind I'm not saying it ought to block a v1 of this API, just that it's worth considering. As soon as we offer an API that says, "Hey, this API will identify bad actors in your third-party scripts!" (which is what MSN is interested in BTW), then those script authors will inevitably start to look for loopholes.

Given Chrome has async stacktraces in the Dev Tools, I'm guessing this is something you could potentially measure? Or is it out of scope?

[domenic]

For the async stack traces question, you are thinking if people recursively break up their tasks? I guess that might be trackable, but it doesn't seem to help if people just run them sequentially, instead of recursively... Fighting bad actors does seem like a hard fight :(

[igrigorik]

In the case of MutationObserver or Promises, it's possible to jank the main thread with 50 microtasks that each take 1ms, thus exceeding the 50ms threshold but not showing up as a "long task" because it was 50 separate operations.

True, but I think it's important to note that 50x 1ms tasks is already a huge improvement over a monolith 50ms task, as it allows us to interleave work.

[spanicker]

Great question and great discussion!
If there's a large number of microtasks taking up long enough time, their CPU time should be reflected in the top-level message loop task (it includes micro tasks).

That said, attribution for these microtasks will be quite tricky, if at all possible.
In the initial implementation we won't be able to attribute them to the misbehaving iframe.
However it is NOT out-of-scope and certainly worth looking into further.

It would be great to construct a few test cases with the scenario you are describing to get an idea of impact of short bursts of micro-tasks (they'll likely cause jank, but not block user input)

Agree with Ilya that breaking up 50+ms tasks into smaller tasks (including promises) should be an improvement overall.

PS: As an aside, we are kicking around the idea of a separate API for "CPU busyness" that includes all tasks taking up CPU time including micro tasks (targeted towards battery usage). But it's too early to have a productive discussion on that.

[nolanlawson]

Thanks for the feedback! Just to see how attribution works in the "50x 1 ms" microtasks situation works in practice, I put together a tiny benchmark that does 1000 1ms microtasks every 2 seconds, you can see it blocks keyboard scrolling in Chrome/Edge/Firefox: http://bl.ocks.org/nolanlawson/raw/0e74f3d8d6d0cc07e02fc2f7aac579bf/

Might be worth running your prototype on this page to see how attribution works. (Also happy to modify it to make it more useful.)

[igrigorik]

To close the loop, LT v2 and related discussions: https://docs.google.com/document/d/125d69JAC7nyx-Ob0a9Z31d1uHUGu4myYQ3os9EnGfdU/edit