search

w3c / navigation-timing

Navigation Timing
https://w3c.github.io/navigation-timing/
Other
116 stars 30 forks source link

Timings for beforeUnload event #79

Closed andydavies closed 6 years ago

andydavies commented 6 years ago

Navigation Timing doesn't contain any timings for the beforeUnload event.

As beforeUnload is triggered at the 'start of the navigation' from one page to the next, it's execution time affects users' experience

Some sites hook the event to determine whether it's safe to navigate e.g. will unsaved changes be lost, others use it to gather, compress and beacon back UX type data e.g. mPulse Resource Timing data, Tealeaf with DOM nodes.

I've observed beforeUnload event handlers take over 2s on mobile, so our current lack of timings leaves a blind spot and page timings that may not reflect actual users' experience.

I'm less sure about how we should record the timings for them though - moving the time origin seems a non-starter, as does having -ve values relative to time origin.

nicjansma commented 6 years ago

Yeah... for everyone else's sake, let's quickly review navigationStart:

https://w3c.github.io/navigation-timing/#dom-performancetiming-navigationstart

This attribute must return the time immediately after the user agent finishes prompting to unload the previous document. If there is no previous document, this attribute must return the time the current document is created.

The prompt to unload is when beforeunload is run.

IIRC the original intent was that navigationStart shouldn't begin until the navigation was committed to happening -- and since beforeunload could (technically) cancel the navigation, navigationStart shouldn't happen until after it had the chance to cancel it. So navigationStart is after beforeunload, right before unload is triggered.

This presents the challenge you bring up -- in reality, the user's perception of what happened after the event that triggered the navigation sequence (such as user click) will be affected by long beforeunload handlers. But we probably shouldn't at this point try to redefine navigationStart to be earlier. And if not, since beforeunload happens before navigationStart, it would have a "negative" timestamp in relation to navigationStart (the time origin).

Getting rid of timestamps completely:beforeUnloadDuration? :)

yoavweiss commented 6 years ago

Do we want to expose this data to the next page, or do we want to expose it to the current one?

andydavies commented 6 years ago

Next page for me

  1. It's part of the critical path for the next page
  2. As many RUM products use beforeUnload to beacon data back, they wouldn't be able to grab the timings

@nicjansma I quite like duration, even though it's a different model to the other timings as not keen on -ve timings

What the timings look like when someone is prompted to cancel the navigation and they take a long time to respond might need a bit of thought.

yoavweiss commented 6 years ago

I'm guessing there will be some privacy/security consideration then for everything cross-origin (e.g. I'm not sure BigSearchEngineCompany.com would want every random site to be able measure what it does at beforeunload)

cvazac commented 6 years ago

I like beforeUnloadDuration, but IMO it's value is lessened if we don't also measure total user "think time" - that is, time spent waiting for the user to dismiss an alert|confirm|prompt.

As for privacy/security, a script inlined in the page can measure these things: https://gist.github.com/cvazac/4f22883563a334e03365a1c0c478fe92

toddreifsteck commented 6 years ago

Moving to L3 as this is a request for new functionality.

igrigorik commented 6 years ago

As discussed on the last call, unfortunately we cannot expose "duration of beforeunload of the previous" page to the next page. Doing so would leak private data both about the previous page, as well as the user if a prompt is presented. The current definition is specifically crafted to avoid this (as @nicjansma already noted earlier in https://github.com/w3c/navigation-timing/issues/79#issuecomment-347391151) and this behavior is by design.

Closing as a wontfix.

andydavies commented 6 years ago

Not even with a same origin restriction?

igrigorik commented 6 years ago

Same origin pages can already record and report this: instrument beforeunload and use sendBeacon to report the necessary timestamps.

andydavies commented 6 years ago

Don't see how this works - a site can instrument a beforeunload handler it adds but what about the ones 3rd party scripts add?

Currently gathering data on this and will be back when I've got it together