Intent to Implement and Ship: buffered flag for longtasks

[Nicolás Peña]

Contact emails

n...@chromium.org

Explainer

Buffered flag: https://github.com/w3c/performance-timeline/#buffered-flag

This intent is about adding the buffering behavior to the Long Task API.

Design doc/Spec

Buffered flag: defined here, associated registry is here.

Longtasks: defined here.

TAG review is being skipped as this just shipping the buffered flag for longtasks, and this flag already shipped for all other entry types.

Summary

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

Motivation

We initially shipped the PerformanceObserverInit buffered flag without longtasks because PerformanceLongTaskTiming entries are not currently being created if there is no PerformanceObserver observing them. There is no need for these entries without the buffered flag because there is no PerformanceTimeline support for longtasks: they cannot be queried via performance.getEntries(). Nonetheless, Blink’s PerformanceMonitor already receives task durations, so creating these entries would be pretty easy.

Buffering these entries is useful because many longtasks occur early during page load. Without the buffered flag, a developer cannot gain insight into very early long tasks and is incentivized to run a script registering a PerformanceObserver early on, which is something we want to avoid for performance reasons. After a discussion with the WebPerf WG, we decided to use a buffer of size 200 (so at most 200 longtask entries will be stored).

Risks

Interoperability and Compatibility

I presented this during a WebPerf WG call, see minutes.
Edge: no signals (we no longer have someone from Microsoft regularly attending our calls). Eric Lawrence CCd in case he has thoughts.

Firefox: positive signals from the call

Safari: no signals, sent FYI here

Web / Framework developers: positive. SpeedCurve has requested it, Akamai would use it too, Microsoft asked for it.

Ergonomics

This flag is used in the observe() call of PerformanceObserver, using ‘type’ to specify the entry type, for example po.observe({type: ‘longtask’, 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?

https://github.com/web-platform-tests/wpt/blob/master/longtask-timing/buffered-flag.window.js

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

[Daniel Vogelheim]

On Mon, Dec 2, 2019 at 7:15 PM Nicolás Peña <n...@chromium.org> wrote:

Contact emails

n...@chromium.org

Explainer

Buffered flag: https://github.com/w3c/performance-timeline/#buffered-flag

This intent is about adding the buffering behavior to the Long Task API.

Design doc/Spec

Buffered flag: defined here, associated registry is here.

Longtasks: defined here.

TAG review is being skipped as this just shipping the buffered flag for longtasks, and this flag already shipped for all other entry types.

Summary

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

Is that buffer maintained per page load? I mean, if observe() is called before the current page has exhausted its 200 buffer items, could the buffer still include entries from previous activity?

 

Motivation

We initially shipped the PerformanceObserverInit buffered flag without longtasks because PerformanceLongTaskTiming entries are not currently being created if there is no PerformanceObserver observing them. There is no need for these entries without the buffered flag because there is no PerformanceTimeline support for longtasks: they cannot be queried via performance.getEntries(). Nonetheless, Blink’s PerformanceMonitor already receives task durations, so creating these entries would be pretty easy.

Buffering these entries is useful because many longtasks occur early during page load. Without the buffered flag, a developer cannot gain insight into very early long tasks and is incentivized to run a script registering a PerformanceObserver early on, which is something we want to avoid for performance reasons. After a discussion with the WebPerf WG, we decided to use a buffer of size 200 (so at most 200 longtask entries will be stored).

Risks

Interoperability and Compatibility

I presented this during a WebPerf WG call, see minutes.
Edge: no signals (we no longer have someone from Microsoft regularly attending our calls). Eric Lawrence CCd in case he has thoughts.

Firefox: positive signals from the call

Safari: no signals, sent FYI here

Web / Framework developers: positive. SpeedCurve has requested it, Akamai would use it too, Microsoft asked for it.

Ergonomics

This flag is used in the observe() call of PerformanceObserver, using ‘type’ to specify the entry type, for example po.observe({type: ‘longtask’, 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?

https://github.com/web-platform-tests/wpt/blob/master/longtask-timing/buffered-flag.window.js

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

--
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/d84f4594-52c3-4e72-965c-c223bbf69e56%40chromium.org.

[Nicolás Peña]

On Tuesday, December 3, 2019 at 8:46:32 AM UTC-5, Daniel Vogelheim wrote:

On Mon, Dec 2, 2019 at 7:15 PM Nicolás Peña <n...@chromium.org> wrote:

Contact emails

n...@chromium.org

Explainer

Buffered flag: https://github.com/w3c/performance-timeline/#buffered-flag

This intent is about adding the buffering behavior to the Long Task API.

Design doc/Spec

Buffered flag: defined here, associated registry is here.

Longtasks: defined here.

TAG review is being skipped as this just shipping the buffered flag for longtasks, and this flag already shipped for all other entry types.

Summary

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

Is that buffer maintained per page load? I mean, if observe() is called before the current page has exhausted its 200 buffer items, could the buffer still include entries from previous activity?

The buffer is per frame. A buffer does not include entries from previous page loads, of course.

[Yoav Weiss]

Thanks for working on this. This will align all entries to be buffered, and enable developers to collect all their entries without adding an inline script at the <head>.

LGTM1

On Mon, Dec 2, 2019 at 7:15 PM Nicolás Peña <n...@chromium.org> wrote:

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh5SShpKoZ99-aeOwEL7Du-NFTAcqTN-utM6HNnuLw3uw%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7101a3ad-fa63-38c6-1514-fd0d34613799%40gmail.com.