Proposal: add timestamp for when "activation" or "dismissal" starts

[noamr]

Currently page deactivation (specifically calling pagehide and visibilitychange) is done some time after responseStart and before the new page is activated, but it's unclear how long they took.
This becomes more important with the introduction of cross-document view transitions, as the browser might add a rendering step between the new page's response headers being ready and deactivating the old document.

Proposing to add deactivationStart or some such to PerformanceNavigationTiming, that marks the time right before firing pagehide & visibilitychange (both of which fire before unload). This will only be accessible in same-origin navigation.
In addition, we should finish specing and implementing w3c/resource-timing#345 - if we have finalResponseHeadersEnd and deactivationStart, the time in between would often mean the time spend preparing a view-transition.

/cc @tunetheweb @fergald @yoavweiss

[fergald]

Should there be a deactivationEnd? I think it should be at the basically the same time as unloadEventEnd, which makes it somewhat redundant but for symmetry and for a future where hopefully there is no unload event it would be nice to have.

[nicjansma]

Discussed on the March 13, 2024 W3C WebPerf call: https://docs.google.com/document/d/1k7lB7XWXHBUmxR5YaycYTXWsHVqXelLh0RRDIFnx-gI/edit#heading=h.t4ndg6qhajam

• Noam went over the proposal a bit further, clarifying what it could measure and how it can help identify troublesome page event handlers (on the previous page)
• These types of measurements could be done by a site on its own (transitioning measurements to the next page), but these timestamps would offer a convenience
• Next steps is for RUM vendors to talk to their customers / consumers and see if this is impacting folks that are trying to measure view-transitions, and report back