You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to produce accurate BFCache hit-rate stats a page must be able to tell whether a navigation was even eligible for BFCache in the first place. Currently there is not enough information available from APIs to tell this. Pages which are the result of a session-restore or a tab-clone of a history navigation cannot be distinguished from genuine history navigation.
Steps to demonstrate the issue
go to a page (A) that cannot be BFCached
go to any other page (B)
go back to A
In JS, execute performance.getEntriesByType('navigation')[0].type and you will see back_forward.
clone the tab or quit the browser and restart
In JS, execute performance.getEntriesByType('navigation')[0].type and you will still see back_forward.
Session cookies could be used to detect a session restore. I can't think of anything that could be used to detect a tab-clone.
Should we have something else to indicate that the current navigation is from a session-restore or tab clone?
The proposed not-restored reason API could expose this e.g. by presenting an "ineligible" reason when the last navigation was ineligible for BFCache. Perhaps it would be simpler and more useful to present directly whether the current page came from restore/clone. This would provide more information, in the case where the previous navigation was not back_forward since those navigations are also ineligible regardless of session-restore/clone.
I don't think so. I could imagine that it might tell in the case of a session restore (but in my testing with Chrome it is not true on session restore) but for a tab clone, I don't think there would be any expectation that it might be true.
In order to produce accurate BFCache hit-rate stats a page must be able to tell whether a navigation was even eligible for BFCache in the first place. Currently there is not enough information available from APIs to tell this. Pages which are the result of a session-restore or a tab-clone of a history navigation cannot be distinguished from genuine history navigation.
Steps to demonstrate the issue
performance.getEntriesByType('navigation')[0].type
and you will seeback_forward
.performance.getEntriesByType('navigation')[0].type
and you will still seeback_forward
.Session cookies could be used to detect a session restore. I can't think of anything that could be used to detect a tab-clone.
Should we have something else to indicate that the current navigation is from a session-restore or tab clone?
The proposed not-restored reason API could expose this e.g. by presenting an "ineligible" reason when the last navigation was ineligible for BFCache. Perhaps it would be simpler and more useful to present directly whether the current page came from restore/clone. This would provide more information, in the case where the previous navigation was not
back_forward
since those navigations are also ineligible regardless of session-restore/clone.@domenic @yoavweiss
The text was updated successfully, but these errors were encountered: