The LCP spec, element timing, container timing, and the proposed new interaction contentful paint, all define renderTime.
These days, this value should always be max(paintTime, presentationTime), so it seems a bit redundant.
But, not all platforms have a presentationTime, and in Chromium, although it is currently always available, there are a few reasons why it might start to become optional (Event Timing doesn't always measure next paint, and PaintTimingMixin sometimes cannot measure next presentation and should support fallbacks...)
For these reasons, exposing a renderTime that "does the right thing" is convenient. It is redundant to re-define for each user spec that integrates PaintTimingMixin, and it is not great to expect every JS snippet to test for these values manually.
The LCP spec, element timing, container timing, and the proposed new interaction contentful paint, all define
renderTime.These days, this value should always be
max(paintTime, presentationTime), so it seems a bit redundant.But, not all platforms have a
presentationTime, and in Chromium, although it is currently always available, there are a few reasons why it might start to become optional (Event Timing doesn't always measure next paint, and PaintTimingMixin sometimes cannot measure next presentation and should support fallbacks...)For these reasons, exposing a renderTime that "does the right thing" is convenient. It is redundant to re-define for each user spec that integrates PaintTimingMixin, and it is not great to expect every JS snippet to test for these values manually.