Re: Long Tasks Notifications API

Hey Ben,
Thanks for the quick response!

1) Re: the 50 ms threshold
There's couple reasons for the picking 50ms recommendation:
a.  > 50ms is a real risk to user responsiveness. See RAIL
<https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en>
guideline.
     The API is intended as a notification of something bad that requires
attention.
b. it is safe to expose from privacy & security perspective. Fine grained
timing in the 10ms range opens up the attack surface.
   (will share more detailed doc on Privacy / Security with you if
interested)

Note that high overhead of instrumentation is not one of the reasons - as
we do measure all tasks.

2) Great point.
This attribution is targeted for the V2 API i.e. pointing to the type of
task (script vs style / layout), and for the case of scripts including the
culprit URL
So it will come just not in V1 :)
Please take a look at the writeup
<https://docs.google.com/document/d/1J0brr10eHRpk0F6tRaWzkgI3mHja3SOHR6fwHBGzGs0/edit>
mentioning
script URL attribution, if you haven't already.

3) "long task" events from early in the lifecycle of the page -- way before
any scripts -- are typically not a risk to user responsiveness.
And there isn't a compelling reason to worry about long tasks during that
time AFAIK
So I'm not sure it's worth buffering and delivering those.




On Thu, Aug 4, 2016 at 5:44 PM, Ben Maurer <ben.maurer@gmail.com> wrote:

> (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)
>>
>
>