Re: Long Tasks Notifications API

Hey,

On Fri, Aug 5, 2016 at 8:41 AM, Shubhie Panicker <panicker@google.com>
wrote:

> 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.
>

I think there's use cases here beyond measuring RAIL responsiveness -- for
example, we use the 10 ms timer to try to figure out times when the event
loop is idle so that we can infer network performance.

[image: Inline image 1]

In this example, the server processes newsfeed and we only receive it on
the client after the second script has executed. If the time marked Idle is
truly idle time we can conclude that the client didn't receive the newsfeed
until sometime during the second script execution -- ie, that we could
speed up the page by making the newsfeed generate faster or by making the
contents smaller. But if the idle time is actually layout or some other
task it may be that the client actually received newsfeed earlier, but
wasn't able to process it. Being able to measure the time of smaller tasks
(sub 50 ms) gives us a better picture of when the main thread is idle





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

How hard is this to add for 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.
>

I think fb might actually defeat the work done in script url attribution.
Often times our callbacks are wrapped (eg, we have an internal api
Event.listen which installs an event listener and adds a wrapper around it
for measurement purposes). So the vast majority of events would probably
blame to the file that has the abstraction. What would be helpful here is
if we could annotate function objects with a name (Function.__profilingName
= "...")

One other thought re: attribution -- how are extensions handled? Would it
be possible to have a source that tells us an extension is responsible
(even if you can't identify which?)


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.
>

Yes, but I think that this api is (or should be) more than about just
responsiveness -- it's the web developers only insight into the usage of
the main thread. We've found that there are often gaps early in the page
that are difficult to explain and having something that says "the main
thread was busy" would help us better annotate/investigate this time.

-b