From 94d5430e702cfef9c9594b8b65c6b202f109044c Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 19 Nov 2025 10:41:09 +0000 Subject: [PATCH 1/2] Enhance presentation-timestamps.md with new sections Added a section on user value and considered alternatives to improve clarity on performance monitoring. --- presentation-timestamps.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/presentation-timestamps.md b/presentation-timestamps.md index be7c57e..ffd5642 100644 --- a/presentation-timestamps.md +++ b/presentation-timestamps.md @@ -12,6 +12,11 @@ In addition, the "long animation frame" timing exposes the hand-over time as its The `PaintTimingMixin` attempts to clean up this confusion, by always providing two timestamps, one mandatory and interoperative, one optional and somewhat implementation-defined. +## User value +Real user monitoring (RUM) is an important part of the ecosystem of measuring performance, which is a big contributor to user experience. +This proposal makes the data fed to these solutions easier to understand and more consistent across entries, +making it easier for these solutions to explain performance regressions to the website authors, and thus improve them for users. + ## `PaintTimingMixin` `PaintTimingMixin` is a mixin that would be included in the interfaces representing all the relevant performance entries: @@ -42,6 +47,10 @@ Currently paint timing's `startTime` and element timing's `renderTime` use the p In this proposal, this would be explicit: both paint timing's `startTime` and element timing's `renderTime` would return something like `presentationTime || paintTime`. This would keep compatibility with what's out there today, allowing progressive enhancement and returning the "best known value" from these attributes. +## Considered alternatives +An alternative to this would be keeping the status-quo, where presentation timings are included in some performance entries and not others, +creating confusion for RUM solutions and requiring more processing of entries to find overlaps. + ## Conclusion When exposing paint timings, we look for the right trade-off between "UX-precise" and "interoperable". From 287840e13c60c377533244d796eb943d2b764add Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 19 Nov 2025 10:44:16 +0000 Subject: [PATCH 2/2] Enhance clarity on alternatives for presentation timings Clarify the drawbacks of the status-quo approach regarding presentation timings. --- presentation-timestamps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/presentation-timestamps.md b/presentation-timestamps.md index ffd5642..64cb4e0 100644 --- a/presentation-timestamps.md +++ b/presentation-timestamps.md @@ -49,7 +49,7 @@ This would keep compatibility with what's out there today, allowing progressive ## Considered alternatives An alternative to this would be keeping the status-quo, where presentation timings are included in some performance entries and not others, -creating confusion for RUM solutions and requiring more processing of entries to find overlaps. +creating confusion for RUM solutions and requiring more processing of entries to find overlaps, as well as delicate interoperability issues. ## Conclusion