Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
mmocny opened this issue Dec 21, 2022 · 2 comments
Open

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

mmocny opened this issue Dec 21, 2022 · 2 comments
Assignees
@mmocny

Comments

@mmocny
Copy link
Contributor

mmocny commented Dec 21, 2022

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.
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Dec 21, 2022
@chromium-wpt-export-bot
Ignore presentation time if visibility changed, for Event Timing
cfd7f0a 
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
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 17, 2023
@chromium-wpt-export-bot
Ignore presentation time if visibility changed, for Event Timing
bb01009 
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
aarongable pushed a commit to chromium/chromium that referenced this issue Jan 17, 2023
Ignore presentation time if visibility changed, for Event Timing
4d3219d 
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 17, 2023
@chromium-wpt-export-bot
Ignore presentation time if visibility changed, for Event Timing
ac2138e 
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 17, 2023
@chromium-wpt-export-bot
Ignore presentation time if visibility changed, for Event Timing
961cd01 
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}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 20, 2023
@moz-wptsync-bot
Bug 1801444 [wpt PR 37039] - Ignore presentation time if visibility c…
c543297 
…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
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jan 25, 2023
@moz-wptsync-bot
Bug 1801444 [wpt PR 37039] - Ignore presentation time if visibility c…
ab28103 
…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 mmocny self-assigned this Feb 27, 2023
@mmocny
Copy link
Contributor Author

mmocny commented Apr 21, 2023

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
Copy link
Contributor Author

mmocny commented Aug 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mmocny mmocny

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mmocny