Consider measuring Events until alternative end points (i.e. visibility change, page unload, URL update for same-document navigations, fullscreen) #129

mmocny · 2022-12-21T21:23:49Z

This is related to #123, which explores cases where the End point of Event Timing measures is not the next paint.

That issue suggests falling back just to the processingEnd time of the Event.

However, sometimes there are better alternatives which capture some really important durations that do affect user experience, and where it would be very important to report on long delays.

Example:

Page unload. Clicking a link which navigates away before next paint... would still be worthwhile to measure how long it took to initiate the navigation.
Tab visibility changes. While this even negates the ability to measure to next paint... it is still a bad interaction if the visibility changes takes a long time to trigger.
Fullscreen API which resizes the viewport. It may take quite a bit longer until the next paint with the new viewport size updated, but visually for the user there was an update as soon as fullscreen was applied.
The moment URL updates when doing a same-document navigation. Especially when using the new navigation API which shows a browser-UI driven loading indicator. The Next Paint may be quite a bit later than the navigation initiates and gives feedback via browser UI.

The text was updated successfully, but these errors were encountered:

EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b

EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452}

EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452}

…hanged, for Event Timing, a=testonly Automatic update from web-platform-tests Ignore presentation time if visibility changed, for Event Timing EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452} -- wpt-commits: 961cd0162bcebbb0acfe94bbf21a5ece067374d0 wpt-pr: 37039

mmocny · 2023-04-21T15:41:25Z

Some more use cases:

alert()
prompt()
confirm(), including beforeunload event prompt to conform unsaved data
print()

While some of these modals are generally discouraged due to the performance issues with long synchronous blocking of the browser main thread-- there are some valid use cases and usage is still significant.

mmocny · 2024-08-19T14:52:03Z

Related to #131 and also w3c/paint-timing/issues/62.

Specifically, I think all "paint timings" (which Event Timing is, effectively) should expose all of the raw timings:

paintTime
presentationTime
renderTime (which is just the min(paintTime, presentationTime)

Then, values like event timing duration can just be defined in terms of the "minimum value of the above".

Once that happens, this issue becomes:

alternative-to-paintTime, and add it to the list of paint timings to consider for duration

This is similar to how loadTime is a fallback for element timing.

chromium-wpt-export-bot mentioned this issue Dec 21, 2022

Ignore presentation time if visibility changed, for Event Timing web-platform-tests/wpt#37039

Merged

mmocny self-assigned this Feb 27, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consider measuring Events until alternative end points (i.e. visibility change, page unload, URL update for same-document navigations, fullscreen) #129

Consider measuring Events until alternative end points (i.e. visibility change, page unload, URL update for same-document navigations, fullscreen) #129

mmocny commented Dec 21, 2022

mmocny commented Apr 21, 2023

mmocny commented Aug 19, 2024

Consider measuring Events until alternative end points (i.e. visibility change, page unload, URL update for same-document navigations, fullscreen) #129

Consider measuring Events until alternative end points (i.e. visibility change, page unload, URL update for same-document navigations, fullscreen) #129

Comments

mmocny commented Dec 21, 2022

mmocny commented Apr 21, 2023

mmocny commented Aug 19, 2024