Intent to Implement: Long Task Notifications
Shubhie Panicker
Contact emails
pani...@google.com, igri...@google.com, nd...@google.com
Spec
Explainer: https://github.com/spanicker/longtasks
WICG thread: https://discourse.wicg.io/t/proposal-long-task-notifications-in-performance-observer/1613
Discussed the API with W3C Web-Perf group at last F2F. Overall the response was positive.
There is strong interest in this API from RUM vendors - such as SOASTA.
The spec has not been drafted yet.
Summary
A new performance API to enable applications to detect presence of “long tasks” that monopolize the UI thread for extended periods of time and block other critical tasks from being executed - e.g. reacting to user input.
Initial work and preliminary data confirm that the API is very promising as an indicator of how performance-tuned the site is, and the user's experience on it. It also demonstrate that the API is not inordinately difficult to implement.
Motivation
See Explainer for detailed motivation.
Browser engines are essentially single threaded (although there are dedicated threads for certain types of tasks). Long running tasks will block other tasks from completing.
Long tasks causing CPU contention is a major source of a lot of bad user experiences on the web today:
delayed “time to Interactive”, high/variable input latency, high/variable event handling latency, janky animations and scrolling (some animation and scrolling interactions require coordination between compositor and main threads).
Lack of RUM APIs have driven many developers and RUM vendors to hacky workarounds to guess whether the main thread is busy such as polling with periodic timer. This has several bad performance implications: the application is polling to detect long tasks, which prevents quiescence and long idle blocks; it’s bad for battery life; there is no way to know who caused the delay (e.g. first party vs third party code)
RAIL performance model suggests that applications should respond in under 100ms to user input; for touch move and scrolling in under 16ms. Our goal with this API is to surface notifications about tasks that may prevent the application from hitting these targets.
Interoperability and Compatibility Risk
Low.
Notifications will be exposed via well-defined Performance Observer interface and require explicit opt-in from application; notifications themselves have standard performance-entry format.
Finally, this will implemented behind a flag.
Ongoing technical constraints
“None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.