measuring bfcache latency

[Fergal Daly]

Performance measurement folks

Carlos from Google Search has been trying to measure BFCache latency and has run into inconsistency across browsers. I hope you can shed light on what the spec says about this. From Carlos:

On Chrome, since the pageShowEvent timestamp is set to the navigationStart of the BFCache navigation relative to the origin of the first navigatio, we can simply subtract it from performance.now(), which is also relative to the origin of the first navigation.

On Safari, navigationStart is updated on BFCache navigation. It is an absolute timestamp while performance.now() is relative to the original navigation. Consequently, we have to first make the BFCache navigationStart relative to the originalNavigationStart before subtracting it from performance.now() to calculate the latency.

I tried the second one on Firefox since navigationStart is also an absolute timestamp but the numbers do not make sense to me (way bigger than a BFCache hit latency ~80ms or less from a faster device). 

Is this stuff specced? Which browsers are doing it wrong?

Thanks,

F

[Yoav Weiss (@Shopify)]

+Noam Rosenthal who I believe specified (or revamped the spec) around time origin and navigation timing.

[Noam Rosenthal]

Hi folks

Hi!

First of all, timeOrigin replaced navigationStart which has been deprecated. (https://developer.mozilla.org/en-US/docs/Web/API/Performance/timeOrigin)

However, I recommend using neither for the purpose of aligning timestamps from two different windows. See:

https://dev.to/noamr/when-a-millisecond-is-not-a-millisecond-3h6

Tl;dr: If the original page was open for many minutes/hours, and especially on windows, the time origin can drift by significant amounts. 

So the recommended way to go about aligning timelines is to call `new Date().valueOf() - performance.now()` on both pages with as little delay as possible.

However, since here you actually want to compare the latency of the navigation itself rather than compare whole timelines, I'd say - don't use monotonic time! The drift would take the edge away from using monotonic time in the first place, and would make it less accurate than using wall clock time (comparing new Date().valueOf() before and after the BFCache navigation).

 

Thanks,

F

[Fergal Daly]

Thanks Noam. Replies below.

On Tue, 6 Feb 2024 at 18:59, Noam Rosenthal <nrose...@chromium.org> wrote:

Hi folks

On Tue, Feb 6, 2024 at 9:31 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

+Noam Rosenthal who I believe specified (or revamped the spec) around time origin and navigation timing.

On Mon, Jan 29, 2024 at 1:30 PM Fergal Daly <fer...@google.com> wrote:

Performance measurement folks

Carlos from Google Search has been trying to measure BFCache latency and has run into inconsistency across browsers. I hope you can shed light on what the spec says about this. From Carlos:

On Chrome, since the pageShowEvent timestamp is set to the navigationStart of the BFCache navigation relative to the origin of the first navigatio, we can simply subtract it from performance.now(), which is also relative to the origin of the first navigation.

On Safari, navigationStart is updated on BFCache navigation. It is an absolute timestamp while performance.now() is relative to the original navigation. Consequently, we have to first make the BFCache navigationStart relative to the originalNavigationStart before subtracting it from performance.now() to calculate the latency.

I tried the second one on Firefox since navigationStart is also an absolute timestamp but the numbers do not make sense to me (way bigger than a BFCache hit latency ~80ms or less from a faster device). 

Is this stuff specced? Which browsers are doing it wrong?

Hi!

First of all, timeOrigin replaced navigationStart which has been deprecated. (https://developer.mozilla.org/en-US/docs/Web/API/Performance/timeOrigin)

I don't see any mention of BFCache there. Is this fixed for the life of the document?

Is there something else that tells you when the most recent navigation-to started?

 

However, I recommend using neither for the purpose of aligning timestamps from two different windows. See:

https://dev.to/noamr/when-a-millisecond-is-not-a-millisecond-3h6

Tl;dr: If the original page was open for many minutes/hours, and especially on windows, the time origin can drift by significant amounts. 

So the recommended way to go about aligning timelines is to call `new Date().valueOf() - performance.now()` on both pages with as little delay as possible.

For measuring BFCache navigation performance, there should be no concern about drift. They're only trying to measure from click to some event in the destination document (I guess pageshow).

However, since here you actually want to compare the latency of the navigation itself rather than compare whole timelines, I'd say - don't use monotonic time! The drift would take the edge away from using monotonic time in the first place, and would make it less accurate than using wall clock time (comparing new Date().valueOf() before and after the BFCache navigation).

It seems that would require passing the time from one document to the next or performing the diff in the logs pipeline right? Not impossible but not as easy as grabbing something out of Performance,

F

 

Thanks,

F

[Noam Rosenthal]

On Tue, Feb 6, 2024 at 10:24 AM Fergal Daly <fer...@google.com> wrote:

Thanks Noam. Replies below.

On Tue, 6 Feb 2024 at 18:59, Noam Rosenthal <nrose...@chromium.org> wrote:

Hi folks

On Tue, Feb 6, 2024 at 9:31 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

+Noam Rosenthal who I believe specified (or revamped the spec) around time origin and navigation timing.

On Mon, Jan 29, 2024 at 1:30 PM Fergal Daly <fer...@google.com> wrote:

Performance measurement folks

Carlos from Google Search has been trying to measure BFCache latency and has run into inconsistency across browsers. I hope you can shed light on what the spec says about this. From Carlos:

On Chrome, since the pageShowEvent timestamp is set to the navigationStart of the BFCache navigation relative to the origin of the first navigatio, we can simply subtract it from performance.now(), which is also relative to the origin of the first navigation.

On Safari, navigationStart is updated on BFCache navigation. It is an absolute timestamp while performance.now() is relative to the original navigation. Consequently, we have to first make the BFCache navigationStart relative to the originalNavigationStart before subtracting it from performance.now() to calculate the latency.

I tried the second one on Firefox since navigationStart is also an absolute timestamp but the numbers do not make sense to me (way bigger than a BFCache hit latency ~80ms or less from a faster device). 

Is this stuff specced? Which browsers are doing it wrong?

Hi!

First of all, timeOrigin replaced navigationStart which has been deprecated. (https://developer.mozilla.org/en-US/docs/Web/API/Performance/timeOrigin)

I don't see any mention of BFCache there. Is this fixed for the life of the document?

Correct.

Is there something else that tells you when the most recent navigation-to started?

 

However, I recommend using neither for the purpose of aligning timestamps from two different windows. See:

https://dev.to/noamr/when-a-millisecond-is-not-a-millisecond-3h6

Tl;dr: If the original page was open for many minutes/hours, and especially on windows, the time origin can drift by significant amounts. 

So the recommended way to go about aligning timelines is to call `new Date().valueOf() - performance.now()` on both pages with as little delay as possible.

For measuring BFCache navigation performance, there should be no concern about drift. They're only trying to measure from click to some event in the destination document (I guess pageshow). 

OK, I was assuming here that you're measuring in both documents (which might create a drift), because that's the only way to do that ATM. 

However, since here you actually want to compare the latency of the navigation itself rather than compare whole timelines, I'd say - don't use monotonic time! The drift would take the edge away from using monotonic time in the first place, and would make it less accurate than using wall clock time (comparing new Date().valueOf() before and after the BFCache navigation).

It seems that would require passing the time from one document to the next or performing the diff in the logs pipeline right? Not impossible but not as easy as grabbing something out of Performance,

Gotcha. There is currently no timestamp in the performance timeline that represents the beginning of a BFCache-restore navigation.

Thinking of this a bit in more depth - if you're measuring time between click and the new document's pageshow, this is probably more about event latency in the old document rather than navigation latency. In the non-BFCache case, this is also not measured - the time origin (or. navigationStart) of a normal navigation is when we start fetching the document, not when the link is clicked - which is also not information that should be available cross-oriign.

If we want to somehow report "event timestamp of what caused the navigation" to the new page we'd have to think about this beyond BFCache.

[Fergal Daly]

Yeah in practice they will have to measure from pagehide->pageshow since history navigations are often triggered through the browser UI and there is no "HTML-visible" click,

 

Thanks,

F

[Fergal Daly]

Bringing this up again as there is no clear way to measure this (especially across browser) and Search folk are very interested in it.

On Tue, 6 Feb 2024 at 19:48, Noam Rosenthal <nrose...@chromium.org> wrote:

So I guess in the BFCache case, we would measure from the time where we *would* have started fetching the document but instead restored it from BFCache.

What's the correct venue to bring this up on github?

F