We should gather information on how this will impact the number of page loads which are aborted before their performance is reported.

Nicolas, can you file a bug for the takeRecords work, and block this bug on it?

Is there any update for this bug?

Nicolas, I think we still need to get rough consensus on takeRecords from the web perf WG, right?

No, takeRecords has landed in the spec [1] and has been implemented in Chrome[2].

[1] https://github.com/w3c/performance-timeline/pull/98
[2] https://chromium-review.googlesource.com/c/chromium/src/+/820892

Ah, then this is unblocked!
Thanks!

Old patch here:
https://chromium-review.googlesource.com/c/chromium/src/+/738353

Blink-dev discussion here:
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/takerecords/blink-dev/TgoXNRtA3Zs/Ui7FBuyaBgAJ

I thought we had a new reason to wait on this, but can't seem to recall the reason. Should I start implementing this?

We were waiting on takeRecords, but it has shipped.

Feel free to pick up my old patch.

Actually thinking about this, it's not clear to me we should be doing this before further changes to the Performance Timeline. Delaying the observer callback would just encourage developers to get the entries from the buffer instead of using PerformanceObserver. I think that there are plans to only buffer entries that occur before onload. Until that happens, I think we should punt on this change.

"Delaying the observer callback would just encourage developers to get the entries from the buffer instead of using PerformanceObserver."

I'm not sure this is the case. I think many users of these APIs understand the performance impact of dispatching these lazily. (Analytics frameworks at least will understand this).

My guess is that other consumers likely won't care enough about delayed entries to worry about using the performance timeline.

The point of this bug is to "prevent apps from using this to drive app logic". So this bug is not about analytics providers.

And I suspect that if they use the results to drive app logic then they will care about the fact that the callbacks are delayed, because it will cause noticeable problems.

Ah, sorry. Hopefully if they're driving app logic with perf observer entries, it will be clearly superior to migrate away from performance entries entirely than to poll the performance timeline.

Hopefully developers will realize that polling the timeline is terrible. My guess is that they will?

Hmm well I can implement this change but I should note that I'm not convinced that this is the right thing to do at the moment.

Another potential problem: if we end up doing resource timing updates via PerformanceObserver, the use cases will not work properly with a delayed callback.

Ping. Any update here?