Intent to Prototype: Container Timing

[Chromestatus]

Contact emails

jwilli...@bloomberg.net

Explainer

https://github.com/bloomberg/container-timing

Specification

None

Summary

The Container Timing API enables monitoring when annotated sections of the DOM are displayed on screen and have finished their initial paint. A developer will have the ability to mark subsections of the DOM with the containertiming attribute (similar to elementtiming for the Element Timing API) and receive performance entries when that section has been painted for the first time. This API will allow developers to measure the timing of various components in their pages.

Blink component

Blink>PerformanceAPIs

Motivation

As developers increasingly organize their applications into components there's becoming a demand to measure performance on subsections of an application or a web page. For instance, a developer may want to know when a subsection of the DOM has been painted, like a table or a widget, so they can mark the paint time and submit it to their analytics. Current Web APIs don't help with this. Element Timing is limited due to what it can mark so it can't be used for whole sections. "Largest Contentful Paint" has the same limitations due to being built on top of element timing (and thus can't select components or composite structures like a table) Developers would like to communicate the performance of their own blocks of content in a way that their users or organisation would understand, for example "time to first tweet" for timing when the first tweet component is shown on screen.

Initial public proposal

https://github.com/bloomberg/container-timing

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

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

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5110962817073152?gate=5188959423168512

This intent message was generated by Chrome Platform Status.

[Jeffrey Yasskin]

Could you work on moving this to a CG or WG? With 2 authors from different organizations, you already have enough support to be adopted by the WICG (file an issue at https://github.com/WICG/proposals), but you may also have enough support to get adopted directly into the WebPerf WG. Yoav can help with both.

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/672cffcd.2b0a0220.d9f4a.0540.GAE%40google.com.

[Michal Mocny]

For what it's worth, this topic has been presented several times within the Web Perf WG already, including an excellent update at TPAC which had broad support from the group.

However, Element Timing, which this work further extends, is still in WICG.

-Michal

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXm7BOF8jiPGA6dajbbW5ccbgE7eRMpNyHTKk7_R5%2BHNWA%40mail.gmail.com.