W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2016

Re: Long Tasks Notifications API

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 05 Aug 2016 22:49:36 +0000
Message-ID: <CANMdWTvxDCYw4n13F-F46rKpAGy+uWb_iAAUJ0HtehVGc09fZA@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>, Shubhie Panicker <panicker@google.com>
Cc: Ben Maurer <ben.maurer@gmail.com>, public-web-perf <public-web-perf@w3.org>, Nat Duca <nduca@google.com>
On Fri, Aug 5, 2016 at 3:39 PM Ilya Grigorik <igrigorik@google.com> wrote:

> On Fri, Aug 5, 2016 at 3:22 PM, Shubhie Panicker <panicker@google.com>
> wrote:
>> - Re: extensions
>> We *may* be able to indicate something generic here. Prior investigation
>> <https://codereview.chromium.org/1615523002/> indicates that it's very
>> difficult to properly account for scripts spawned by extensions.
> I think we want to be really careful with this one.. Yes, extensions can
> definitely affect runtime of the page, both in the early stages of the page
> load and while the page is active, and it would be nice to get a handle on
> that. However, we can't simply expose which extensions (e.g. script urls
> and related bits) the user is running due to security/privacy concerns.
> It's a problem worth thinking about, but I would mark it as an explicit
> non-goal for the v1 we're discussing here..

Speculating a bit, I could imagine a response header for the main resource
that instructs the browser to observe long tasks from the beginning of the
page load and make them available to PerformanceObserver. I think it's
probably a solvable problem, but there's a ton of details to work out, so
definitely not a V1 feature. Also, by the time we get around to trying to
solve this, we may have better general RUM support that Shubhie alluded to
and not need to solve it with this API.
Received on Friday, 5 August 2016 23:54:25 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 18 September 2016 16:33:38 UTC