NotRestoredReasons for PerformanceNavigationTiming API

[Yuzu Saijo]

Hi Yoav, (cc: bfcache-dev)

I've been implementing notRestoredReasons field for PerformanceNavigationTiming API ([proposal], [explainer]) and there's one thing I'm not sure about the API behavior.

Let's consider navigation like below:

-- a.com is not bfcache eligible --

nav1 - a.com -> b.com

nav2 - b.com -> a.com -- non-bfcache navigation

-- a.com becomes bfcache eligible --

nav3 - a.com -> b.com

nav4 - b.com -> a.com -- bfcache restore

After nav2 and nav4, performance.getEntryType("navigation")[0] currently stays the same. That is, after successful bfcache restore, we currently don't update PerfNav entry.

(There seems to be no specced behavior here, and Fergal once posted about this [link])

I'm wondering if I should preserve this behavior with the new field "notRestoredReasons".

I could make it so that notRestoredReasons from nav2 stay after nav4, but that seems a bit confusing to me personally.

Or I could make notRestoredReasons update every navigation, including bfcache restore.

Please let me know what you think!

Thanks in advance,

Yuzu

[Yoav Weiss]

+Ian Clelland - who's been working on a separate entry to expose BFCache navigations.

IMO, it makes sense to not update the PerfNav entry after nav4. The bit that may be surprising to folks is that we do update it after nav2. 

I originally thought that the reasons for non-eligibility would be known already at nav1 time, and hence exposed on the NavTiming entry from its beginning. Is that not the case?

[Yuzu Saijo]

Thanks Yoav!

At the time of nav1, we don't know for sure if a.com will be actually restored from bfcache, as the entry might get evicted while a.com is in bfcache, thus the list of reasons are not complete.

Only at the time of navigating to a.com back, we know the complete list of reasons, including eviction status.

[Yoav Weiss]

Yeah, I get that, but that wasn't obvious to me from the explainer. Apologies for missing it.

Are we planning to update both the performance timeline entry and the perf observer entry with this info? The former already gets updated as information is available, while for the latter, that's not the case.. 

[Yuzu Saijo]

Right thanks for the feedback, I will update the explainer accordingly.

I was thinking of updating only Performance Timeline, but I guess it makes sense to update Performance Observer entry too.

2022年9月7日(水) 17:33 Yoav Weiss <yoav...@google.com>:

[Yoav Weiss]

On Wed, Sep 7, 2022 at 10:54 AM Yuzu Saijo <yu...@google.com> wrote:

Right thanks for the feedback, I will update the explainer accordingly.

I was thinking of updating only Performance Timeline, but I guess it makes sense to update Performance Observer entry too.

It kinda does, but at the same time, it's not idiomatic..

Ian - any thoughts on the best way to resolve this?

[Yuzu Saijo]

Friendly ping on this thread. Ian, any thoughts?

Yuzu

[Ian Clelland]

By "update", do you mean that we are treating these performance entries as live objects, and allowing them to change after they have been reported? Or is this just about modifying the API to include new information in some instances?

(That probably affects the rest of my answers, so I'll instead explain what I expect is happening with the new BackForwardCacheRestorationEntry objects, as it relates to NotRestoredReasons)

From your initial example, I would expect the timeline to look like this:

Let's consider navigation like below:
-- a.com is not bfcache eligible --
nav1 - a.com -> b.com

This is a network navigation; a.com is unloaded and its timeline is gone. b.com gets a PerformanceNavigationTimingEntry, with no notrestored reason

 

nav2 - b.com -> a.com -- non-bfcache navigation

This (presumably is a backwards navigation to the same page we started on); I'm not sure if b.com is in the bfcache.

As another network navigation, this is a new page load, so a.com has a fresh timeline with a PerformanceNavigationTimingEntry, with a notrestored reason (I think?)

 

-- a.com becomes bfcache eligible --
nav3 - a.com -> b.com

a.com goes into the bfcache; If this is a "forward-button" navigation, and b.com gets a new page load, then we should report a notrestored reason.

nav4 - b.com -> a.com -- bfcache restore

At this point, a.com does *not* get a new page load. (I think that's the first time in the example that we see a bfcache restore). We don't change the initial timeline entry. Instead, we append a BackForwardCacheRestorationEntry to the timeline, and if there is an observer, then we send the entry there as well.

Analytics on the page should check the initial PerformanceNavigationTiming for any notrestored reason that triggered the last network load, and then can see all of the 

BackForwardCacheRestorationEntry entries to see all of the times that it was subsequently restored from cache.

Am I missing anything from that example?

[Yuzu Saijo]

Thanks for answering the question Ian!

By 'update', I meant to make a change to NotRestoredReasons value in PerformanceNavigationTimingEntry after being reported.

(I was not sure if I should update NotRestoredReasons value upon bfcache restore.)

It sounds like that since bfcache restore is not a real page load, we don't update PerformanceNavigationTimingEntry and that is expected. 

I will make notRestoredReasons value stay the same as well. 

Thanks!

Yuzu

[Fergal Daly]

[+haoliuk]

On Tue, 13 Sept 2022 at 00:03, 'Ian Clelland' via bfcache-dev <bfcac...@chromium.org> wrote:

By "update", do you mean that we are treating these performance entries as live objects, and allowing them to change after they have been reported? Or is this just about modifying the API to include new information in some instances?

(That probably affects the rest of my answers, so I'll instead explain what I expect is happening with the new BackForwardCacheRestorationEntry objects, as it relates to NotRestoredReasons)

From your initial example, I would expect the timeline to look like this:

Let's consider navigation like below:
-- a.com is not bfcache eligible --
nav1 - a.com -> b.com

This is a network navigation; a.com is unloaded and its timeline is gone. b.com gets a PerformanceNavigationTimingEntry, with no notrestored reason

 

nav2 - b.com -> a.com -- non-bfcache navigation

This (presumably is a backwards navigation to the same page we started on); I'm not sure if b.com is in the bfcache.

As another network navigation, this is a new page load, so a.com has a fresh timeline with a PerformanceNavigationTimingEntry, with a notrestored reason (I think?)

 

-- a.com becomes bfcache eligible --
nav3 - a.com -> b.com

a.com goes into the bfcache; If this is a "forward-button" navigation, and b.com gets a new page load, then we should report a notrestored reason.

nav4 - b.com -> a.com -- bfcache restore

At this point, a.com does *not* get a new page load. (I think that's the first time in the example that we see a bfcache restore). We don't change the initial timeline entry. Instead, we append a BackForwardCacheRestorationEntry to the timeline, and if there is an observer, then we send the entry there as well.

Is BackForwardCacheRestorationEntry documented anywhere? Google search finds me https://crrev.com/c/3714558 but I can't find any explainer or spec for it.

F

 

--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAK_TSXK%3DUgYLgTpqkR9s8pemZkoC2m5ywo5E6d5GunS-FO%3DL5A%40mail.gmail.com.