This content originally appeared on Web Performance Calendar and was authored by Noam Rosenthal
Some things happen in a document during navigating away, right before switching to the new document, especially in same-origin navigation scenarios. We’re not currently measuring them in Navigation Timing. Perhaps we should?
Blind spot
This came up whe discussing the ongoing deprecation of the unload event.
Up until now, we measured the unloadEventStart and unloadEventEnd in navigation timing. However, unload is being deprecated, and regardless of that, several other things happen during this time period that are currently a blind spot in navigation timing.
The deactivation flow
What we call the “deactivation flow” or “document swap” works roughly like this, in a same-origin navigation:
- We start receiving the bytes for the response. This is captured by
responseStart. - We receive the headers for the new document, with a status that tells us that we’ve passed all possible redirects and this navigation should be committed, 200 in the normal case. Some HTTP response statuses don’t get us this far – e.g. 204/205.
- With the new cross-document view-transitions feature, we have now an opportunity to capture the current state of the document for the transition, which might take some milliseconds.
- We fire
pagehideandvisibilitychangeevents, which might introduce their own delays. - The old document is unloaded.
- The new document is activated.
Note that the steps following (2) can happen in parallel to downloading the new document’s HTML. However, in the same-origin case they occur on the same thread as the new document, which might cause delay in CPU-bound scenarios.
Additional proposed attributes
To help with this, there is a proposal to add additional attributes to navigation timing and to resource timing:
PerformanceResourcetiming.finalResponseHeadersEnd: will be measured after step 2. This has been discussed in the past.PerformanceNavigationTiming.deactivationStart: will be measured after step 3.PerformanceNavigationTiming.deactivationEnd: will be measured after step 5.
Thoughts, comments?
Have you been facing this? Are you seeing speed issues that might stem from the deactivation flow in the wild? Are you measuring this in ways other than navigation timing? Please let us know…
Thanks and happy holidays!
This content originally appeared on Web Performance Calendar and was authored by Noam Rosenthal
Noam Rosenthal | Sciencx (2023-12-22T21:25:12+00:00) Just one more thing…. Retrieved from https://www.scien.cx/2023/12/22/just-one-more-thing/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.