(1) I think a lower threshold for "long task" might be helpful -- maybe in
the 10-20 ms range. At facebook we currently use a short timer (~16 ms I
think) to detect occupancy of the main thread. The overhead of processing
an entry for a 10 ms long event is a tiny fraction of the actual cost of
that event.
(2) The name attribute seems targeted at the "janky 3rd party JS" use case.
For sites like ours where we have 100% first party content this api doesn't
really help in terms of debugging. Could we give an opportunity for some
kind of high level documentation about what the cause of the task was (eg
"JS execution" "stylesheet/layout")
(3) It'd be useful to be able to get "long task" events from early in the
lifecycle of the page (eg when extensions are running) before a script runs
that can process the observations.
On Thu, Aug 4, 2016 at 5:32 PM, Shubhie Panicker <panicker@google.com>
wrote:
> Hey all,
> I'd like to solicit your feedback on the proposal for surfacing Long Task
> notifications in PerformanceObserver.
> See: https://discourse.wicg.io/t/proposal-long-task-
> notifications-in-performance-observer/1613/1
>
> We just collected some preliminary data
> <https://discourse.wicg.io/t/proposal-long-task-notifications-in-performance-observer/1613/9>
> on some popular sites and the results are looking very promising.
> Comments here or on the WICG thread are very welcome.
>
> Thanks,
> --Shubhie
> (Chrome Engineer)
>