Hi @noamr, thanks for this review request also. We have been discussing paint/presentation timestamps today too, and have a couple of question about the explainer. We would really like to see the (end-)user needs made explicit. We'd also like to know about the alternatives that were considered, and why they found to be unsuitable, again this helps us weigh up the trade-offs. Thank you in advance for any further info you can provide.

Just in case it eases future reference: we put some background info on explainers in the other thread

Hi @noamr. We asked for some additional info in order to complete our review, but we haven't heard back from you, so we're closing this as timed out for now. If you're able to provide the additional info, please re-open, and we'll continue our review.

Hi @noamr, the TAG discussed it today and found some new concerns:

We are aware that the "presentation time" is not well defined, and an accurate definition might be out of the scope of the Web specs. However, the "paint time" as how it's currently defined is not perceivable by the end user. It's somewhere in the middle of the entire rendering pipeline, and there might be an arbitrary delay between this and when the pixel actually shows up on the screen. For this reason, we are unsure whether this "paint time" is a good enough performance indicator to add to the platform.

We are also wondering if new timings in the rendering pipeline could be used to perform side-channel attacks, e.g. exfiltrate canvas data to someone else.

Have you considered alternatives that are more interoperable and better match the page performance from the end users' perspective?

Hi @noamr, the TAG discussed it today and found some new concerns:

We are aware that the "presentation time" is not well defined, and an accurate definition might be out of the scope of the Web specs. However, the "paint time" as how it's currently defined is not perceivable by the end user. It's somewhere in the middle of the entire rendering pipeline, and there might be an arbitrary delay between this and when the pixel actually shows up on the screen. For this reason, we are unsure whether this "paint time" is a good enough performance indicator to add to the platform.

It is the latest interoperable timestamp. It gives the developer indications about what they did that could have contributed to a long paint. It is also consistent across different performance entry types (e.g. LCP and LoAF), which allows correlation. It's a very useful timestamp.

Note that most timestamps in existing entries (e.g. resource timing) are not directly reflecting UX, but are used for attribution - finding the root cause for problematic user experience. Paint timing is one of those.

We are also wondering if new timings in the rendering pipeline could be used to perform side-channel attacks, e.g. exfiltrate canvas data to someone else.

Presentation times are heavily coarsened when not in a cross-origin isolated environment for that reason. This is mentioned in the privacy & security section of the explainer.

Have you considered alternatives that are more interoperable and better match the page performance from the end users' perspective?

This has been discussed for about 4 years, see https://github.com/w3c/paint-timing/issues/62. So, yes, we have considered this, and this is the best alternative we could come up with.

Hi @noamr, the TAG discussed it again at a Breakout today. Thanks for addressing our security and privacy concerns!

Regarding the usefulness, we would like to see more evidence. In particular, a study on when the new paint time is and is not a good performance indicator will help a lot. This will also help developers use it correctly.

The thread https://github.com/w3c/paint-timing/issues/62 didn't discuss much about the usefulness, but mainly focused on the technical soundness of the new paint time. And there are obvious scenarios where the new paint time might not be a good performance indicator. For example: image, video, gaming, video conference, ... (and anything with a significant graphics workload in general). We need a more thorough understanding here.

I agree that https://github.com/w3c/paint-timing/issues/62 doesn't have adequate detail about why we arrived at this specific solution.

For better historical context, I would read through:

• https://github.com/w3c/largest-contentful-paint/issues/104
  • As far back as 2022 this was the proposed solution agreed amongst multiple implementers
  • Was attempted as an interop project in 2023 but was too nascent
  • Was finally done as part of interop 2025 (and is now already part of baseline)
• Far more discussion, and links to Perf WG meeting minutes linked from https://github.com/w3c/largest-contentful-paint/issues/91

But let me also try to summarize the status and value:

• paintTime is technically not a user perceivable timepoint, and technically only marks an internal scheduling timestamp.
• It is not quite as valuable as presentationTime, which indeed does better to capture the effects of graphics workload, and is more accurately representative of user experience.
• However, presentationTime is not interoperably available across all browsers, nor is it strictly better in every way.
  • Chromium has been using this timestamp for various metrics (such as FCP, LCP, Event Timing, etc) for years. Mozilla have signalled a willingness to implement it. Safari has thus far not signalled a willingness to do so.
• paintTime also offers a unique value relative to presentationTime: it marks the final time point of each animation frame on the main thread.
  • Although there is typically a small amount of extra latency to present the frame (and sometimes a large amount of extra latency), it is useful to know the effect of the main thread in isolation for several reasons:
  • As a performance metric, having both paint and presentation times available you can more easily know if the latency was caused by e.g. javascript or style/layout vs e.g. css effects or decode/rasterization work
  • Beyond that, the paintTime is very useful to segment the overall timeline. E.g. if you want to understand what the state of the DOM was, and which tasks affected a long paint, you need to segment by the main thread time only. Presentation time is an asynchronous value and any main thread updates that overlap with this latency don't directly affect the latency.

There is probably a lot more to be said, or some more presentations to share-- but the real TL;DR is:

• It helped make performance timeline interoperable (successfully so!)
• It has proven useful to developers even in implementations that have exposed both values together.