Intent to Ship: Add presentationTime/paintTime to performance entries

[Chromestatus]

Contact emails

nrose...@chromium.org, mmo...@chromium.org

Explainer

https://github.com/w3c/paint-timing/blob/main/presentation-timestamps.md

Specification

https://w3c.github.io/paint-timing/#painttimingmixin

Summary

Expose "paintTime" and "presentationTime" in element timing, LCP, long animation frames, and paint timing. "paintTime" means the time when the rendering phase ended and the browser started the paint phase. "presentationTime" means the time when the "pixels reached the screen", which is somewhat implementation-defined. This feature entry omits event timing, which would be done separately.

Blink component

Blink>PerformanceAPIs

Web Feature ID

performancetiming

Motivation

So far the spec defined the paint time as the time after the "rendering update", when the document hands over rendering to the UA. However, in chromium the exposed paint time (in event timing, element timing, LCP and paint-timing) was different - the approximated VSync time from the compositor, which is important in terms of UX. This created confusion and incompatibility This proposal defines both these timestamps, and exposes them in an identical way in all the relevant entries.

Initial public proposal

https://github.com/w3c/paint-timing/issues/62

TAG review

https://github.com/w3ctag/design-reviews/issues/1013

TAG review status

Pending

Risks

Interoperability and Compatibility

No information provided

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1110) Firefox folks took part of the WebPerfWG meeting where this was discussed/resolved.

WebKit: In development (https://github.com/WebKit/standards-positions/issues/426)

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?

No information provided

Debuggability

No information provided

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

Yes

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

No

Flag name on about://flags

No information provided

Finch feature name

PaintTimingMixin

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/378827535

Estimated milestones

Shipping on desktop	144
Shipping on Android	144
Shipping on WebView	144

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None. This is already part of interop 2025. Note that the TAG review was delayed because some things in the explainer were missing initially.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5162859838046208?gate=5137700305502208

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67347e70.2b0a0220.3644d.01e9.GAE%40google.com

This intent message was generated by Chrome Platform Status.