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
Currently page deactivation (specifically calling
pagehideandvisibilitychange) is done some time afterresponseStartand 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
deactivationStartor some such toPerformanceNavigationTiming, that marks the time right before firingpagehide&visibilitychange(both of which fire beforeunload). This will only be accessible in same-origin navigation.In addition, we should finish specing and implementing w3c/resource-timing#345 - if we have
finalResponseHeadersEndanddeactivationStart, the time in between would often mean the time spend preparing a view-transition./cc @tunetheweb @fergald @yoavweiss