Re: Delaying PerformanceEntry dispatch

On our side, we've decided to temporarily block this on shipping takeRecords
<https://github.com/w3c/performance-timeline/issues/74>, spec pull request
here <https://github.com/w3c/performance-timeline/pull/98>.

We're hoping to target Q1 for this change.

On Mon, Dec 11, 2017 at 10:10 PM Nic Jansma <nic@nicj.net> wrote:

> For our use case, in Boomerang, we currently hook into the 'load' event
> handlers of things like images, then find the resource's ResourceTiming
> entry -- via the PerformanceTimeline -- to get timing details.
>
> We're not (yet) using PerformanceObserver to do this, and it seems
> reasonable to me that a PerformanceObserver would queue entries at idle
> priority.
>
> - Nichttp://nicj.net/
> @NicJ
>
> On 11/27/2017 1:39 PM, Todd Reifsteck wrote:
>
> My personal take is that this is good for performance, but I know there
> are use-cases on the web for pulling records from the Performance Timeline
> immediately.
>
>
>
> I believe it was one of Nic, Yoav or Nate that previously mentioned this.
>
>
>
> -Todd
>
>
>
> *From:* Ben Kelly [mailto:bkelly@mozilla.com <bkelly@mozilla.com>]
> *Sent:* Monday, November 27, 2017 7:24 AM
> *To:* Timothy Dresser <tdresser@chromium.org> <tdresser@chromium.org>
> *Cc:* public-web-perf@w3.org
> *Subject:* Re: Delaying PerformanceEntry dispatch
>
>
>
> On Mon, Nov 27, 2017 at 8:33 AM, Timothy Dresser <tdresser@chromium.org>
> wrote:
>
> Any thoughts on whether this makes sense, and whether you're likely to add
> this delay?
>
>
>
> I filed a bug to discuss it for firefox:
>
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1420913
>
>
>
> On face value it sounds reasonable to me as long as sites have not come to
> rely on immediate notification.  I'm not the primary owner of this feature
> in gecko, though.
>
>
>
> Ben
>
>
>