Intent to Implement and Ship: PerformanceObserverInit buffered flag

90 views
Skip to first unread message

Nicolás Peña

unread,
Jul 9, 2019, 10:56:30 AM7/9/19
to blink-dev

Contact emails

n...@chromium.org 


Explainer

https://w3c.github.io/performance-timeline/#introduction


Design doc/Spec

https://w3c.github.io/performance-timeline/#performanceobserverinit-dictionary


This is a small addition to PerformanceTimeline and designed with input from the WebPerf WG so TAG review is being skipped.


Summary

By calling observer.observe({buffered: true…}), a PerformanceObserver can receive entries that are buffered, i.e. created before this call is executed.


Motivation

The PerformanceObserver is an efficient API to provide developers with access to various PerformanceEntries. Compared to the legacy Performance Timeline, it doesn’t require polling, and enables developers to easily process and report the performance entries they care about, while giving the browser more control over *when* that processing happens. However, the current API encourages developers to register PerformanceObservers as early as possible, or run the risk of missing some early entries, a deficiency that the performance timeline doesn’t suffer from. 

This small addition to the API enables developers to also observe entries that were buffered *before* the observer was registered, enabling them to use PerformanceObserver with all the benefits and none of the downsides, without incentivizing running analytics-related scripts early in the page load.



Risks

Interoperability and Compatibility

There is some risk of other browsers not implementing, but I think it is low because this is a very desirable and easy-to-implement on top of PerformanceObserver.


Proposal discussed in a F2F a couple years ago and more recently at TPAC.


Edge: Public support

Firefox: Positive signals

Safari: Public support

Web / Framework developers: Strong public support, to the point that at some point they did some spec work :)


Ergonomics

This flag is used in the observe() call of PerformanceObserver, using ‘type’ to specify the entry type, for example po.observe({type: ‘mark’, buffered: true}).


Activation

Easy to use: the way to get the entries is the same as before (they will be dispatched to the observer callback).


Debuggability

Direct debugging in JavaScript.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Is this feature fully tested by web-platform-tests?

Most tests concerning the buffered flag are in https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/performance-timeline/


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5118272741572608


Requesting approval to ship?

Yes.


Chris Harrelson

unread,
Jul 11, 2019, 3:31:48 PM7/11/19
to Nicolás Peña, blink-dev
LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/caa0c108-d221-4d13-9435-ed3cbd52a6a2%40chromium.org.

Daniel Bratell

unread,
Jul 11, 2019, 4:29:14 PM7/11/19
to Nicolás Peña, Chris Harrelson, blink-dev
Is all performance information cached forever in case someone comes with a late observer using this flag?

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-Q5S8OQV4Dtc8SvAVYDf_b9DJSwvq2xCSNeM%3DNHV9fUA%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Nicolás Peña

unread,
Jul 11, 2019, 5:37:00 PM7/11/19
to blink-dev, n...@chromium.org, chri...@chromium.org
This change will not impact caching of any of the existing entry types. Note that currently most of these are already available via performance.getEntries(). The one that's not (longtasks) will still not be supported via the buffered flag for the moment. Some of the supported types are just a constant number of entries per frame (NavigationTiming, PaintTiming), others are always buffered (UserTiming). ResourceTiming has a default max buffer size (which the developer can override). For future entry types (ElementTiming, LayoutStability, etc), we plan to have a hard-coded max buffer size, and these new entries will only be accessible via the PerformanceObserver with the buffered flag and not accessible via performance.getEntries(). Thus we limit memory usage while still enabling developers to delay the observer registration for some time without losing on early entries.
LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Daniel Bratell

unread,
Jul 12, 2019, 10:08:51 AM7/12/19
to blink-dev, Nicolás Peña, chri...@chromium.org
LGTM2

/Daniel
LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8498ca85-ac1a-4267-8f56-ce3cffe16ff0%40chromium.org.

Philip Jägenstedt

unread,
Jul 12, 2019, 12:48:04 PM7/12/19
to Daniel Bratell, blink-dev, Nicolás Peña, Chris Harrelson
Reply all
Reply to author
Forward
0 new messages