Hello, fellow web perf enthusiast! Contribute to the 2024 edition happening this December. Click.

Web Performance Calendar

The speed geek's favorite time of year
2023 Edition
ABOUT THE AUTHOR
Noam Rosenthal photo

Noam Rosenthal (@noam, @nomsternom) is a software engineer for Google Chrome's speed metrics team. Co-editor of several web-perf specs and a seasoned web developer.

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:

  1. We start receiving the bytes for the response. This is captured by responseStart.
  2. 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.
  3. 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.
  4. We fire pagehide and visibilitychange events, which might introduce their own delays.
  5. The old document is unloaded.
  6. 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:

  1. PerformanceResourcetiming.finalResponseHeadersEnd: will be measured after step 2. This has been discussed in the past.
  2. PerformanceNavigationTiming.deactivationStart: will be measured after step 3.
  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!