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.

[Yoav Weiss (@Shopify)]

I should know this but do I understand correctly and this is adding `paintTime` and `presentationTime` *on top* of existing attributes such as `renderTime`/`startTime`/etc?

[Michal Mocny]

Yes, on top of.  startTime is defined in terms of renderTime which is now defined in terms of paint/presentation times.

So this just exposes the individual values that were already used for the calculations.

[Yoav Weiss (@Shopify)]

LGTM1

On Wednesday, December 3, 2025 at 4:56:04 PM UTC+1 Michal Mocny wrote:

Yes, on top of.  startTime is defined in terms of renderTime which is now defined in terms of paint/presentation times.

So this just exposes the individual values that were already used for the calculations.

Thank you! exposing those on top of the current attributes means that there's no real compat risk here. Firefox being supportive significantly reduces interop risk.

[Chris Harrelson]

LGTM2

--
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/2f9f3215-7039-4248-976a-b9cb398bded6n%40chromium.org.

[Vladimir Levin]

Can you comment as to what exactly would Chromium measure for presentationTime. It's mentioned as optional in the Gecko intent, and implementation defined here.

I'm wondering if it would expose GPU contention from other renderers that is otherwise not exposed? I realize this is coarse time but I'm trying to understand if there is any new timing information that presentationTime would provide, or is everything already discoverable by other means

Thanks,

Vlad

[Michal Mocny]

Background: presentation time itself has been exposed to many paint-related apis (like LCP), for years already.  This new API doesn't change in any way what is exposed to developers in Chromium-- but today these values are somewhat indirectly and inconsistently reported as startTime, renderTime, or startTime+duration, depending on the api.

This new API was added to help with interop (to make it clearer what values are actually being reported), and to help with developer ergonomics (i.e. make the reporting consistent across entry types).

(Not dismissing the question about reporting risks, but clarifying that this was already evaluated in the past and this feature doesn't change status quo at all.)

Also, I believe Gecko is working towards exposing presentationTime as well.

[Vladimir Levin]

Sounds good. Thanks for the explanation

LGTM3

[Noam Rosenthal]

Note: shipping PaintTimingMixin also gives PerformancePaintTiming its
own toJSON method.
This is a side effect of having additional properties in
PerformancePaintTiming, which, before this change, shared the toJSON
implementation with its superclass (PerformancePaintTiming).

[Mike Taylor]

Sounds good, thanks! I don't think we need additional reviews for such a
minor addition.