Measuring `beforeunload`

[yoavweiss]

The current timeorigin is set when a the navigation request fetch starts, in between beforeunload and the unload event. As a result of that, there's some a timespan between the hardware timestamp of the user's interaction that navigates away and the next navigation that's kinda hard to measure today, even on the same origin.

Arguably, this is measurable using LT/LoAF+EventTiming, but if the user's navigation is delayed on main thread activity that delays the click event or the beforeunload event or the event handlers themselves, that's unlikely to be captured by a PerformanceObserver before the page navigates away.

Given that, it seems like we could measure the last click HW timestamp -> next nav fetch or unload as a separate measurement. How we report it may be tricky though. A few options:

• We could use the Reporting API to report those timestamps.
• PendingBeacon (or whatever we end up calling it) could report that timestamp when available. That would be a change from current thinking about the beacon data itself be completely userland-driven.
• something else??

[mmocny]

I just tried a few experiments, but I'm just learning here and may be making mistakes:

• beforeunload event fires reliably (for me) on both Same origin and Cross origin navigations.
• pagehide, visibilitychange, unload only seem to fire for Same origin navigations (tested chrome and firefox).
• network request for next document starts right after beforeunload finishes (and so overlaps the other unload(etc) events)
• timeOrigin starts with that network request (and so overlaps the other unload(etc) events)
• Next document waits for the previous document unload(etc) events to finish, even if the network request is finished loading -- but this only matters for Same origin navs(?)
• beforeunload is dispatched from within the click event on an anchor element, and so it gets 100% measured by Event Timing (when navigations that come from interactions).
  • Today Event Timing also includes the time inside confirm() dialog that beforeunload can create, and may try to measure Next Paint, but we already have requests to change that.

Here is what I think that all looks like:

---

I think that diagram, which is already the state of measures today (~event timing change), feels correct to me. If the previous document delays loading the next document, it should count towards LCP -- but that seems only possible for Same Origin navigations already.

If redirects delay a Cross Origin navigation, that's tricky but we already have separate issues tracking choices there.

There seems to be a reporting gap to measure final INP -- which gets smaller if we change Event Timing to hard stop at beforeunload processingEnd. Then, the previous page could use PerformanceObserver.takeRecords as part of its last beacon.

The problem I see is: we are recommending visibilitychange as the reliable way to send a final beacon, but that doesn't work reliably. The other events have other reliability issues especially mobile. Useful background

---

If all of that is correct, I think the question becomes: How can we reliably report final Event Timing data that lead to page unload?

...and not to consider this part of navigation timing.

[yoavweiss]

That's an amazing diagram!! Thank you! :)

...and not to consider this part of navigation timing.

I agree this is not necessarily a navigation timing issue. We can move this to a more appropriate repo when we see fit.

[andydavies]

It's a while since I last looked at this in detail but in 2018 the overhead of beforeunload handlers was non trivial

There's some examples on this slide https://noti.st/andydavies/oW1edg/ab-testing-ads-other-3rd-party-tags#sRX5BLv