[Proposal] Back/forward cache NotRestoredReason API

Summary

Back/forward cache(BFCache) is cache optimization that some browser implement to make back/forward button navigation instant.

Today pages can be blocked from BFCache for different reasons, such as reasons required by spec and reasons specific to the browser implementation.

Developers can gather the hit-rate of BFCache on their site by using the pageshow handler persisted parameter and PerformanceNavigationTiming.type(back-forward). However, there is no way for developers to tell what reasons are blocking their pages from BFCache in the wild.

We would like to expand Reporting API and Performance Navigation Timing API to make it possible for sites to collect information on why BFCache is not used on a history navigation, so that they can take actions on each reason and make their page BFCache compatible.

Example

Reporting API lets you observe a deprecated feature usage / browser request intervention / crashes. We would like to have another category “bfcache” here.

Report-To: {
             "max_age": 10886400,
             "endpoints": [{
               "url": "a.com"
             }]
           }
// -> [{URL:"a.com", Id: "x", blocked: True, reasons:["broadcast channel"], children:[]}]

Performance Navigation Timing API tells you the type of navigation (BFCache, prerender). We could also extend this API to report the not-restored reasons.

var perfEntries = performance.getEntriesByType("navigation");
for (var i=0; i < perfEntries.length; i++) {
	console.log("= Navigation entry[" + i + "]");
	var p = perfEntries[i];
	// p.notRestoredReason == [{URL:"a.com", Id: "x", blocked: True, reasons:["broadcast channel"], children:[]}]
}

Hi rubberyuzu,

Thank you for your post. I’m interested to learn what sort of reasons appear only in the field and not on the developer’s test device. Perhaps a list of example reasons would be informative.

Best regards,

Brian

Thanks Brian for the comment!

Here is the list of the reasons that could appear: spreadsheet

My proposal is to mask the reasons when they are from cross origin frames, no matter what reasons they are. So any of the reasons above can be reported or masked depending on which frame in the page caused it.

Please let me know if you have further suggestions, thanks! Yuzu

Thank you, that’s very helpful. I was concerned that if the reasons are mostly reproducible locally then it might be preferable to simply produce console/DevTools warnings rather than introduce a new API which could lead to compatibility issues.

However, looking at the spreadsheet, I can see that reasons like Timeout and CacheLimit will be specific to the user’s device so this API seems helpful for such cases.

Thanks for looking!

We actually already have DevTools Application Panel that reports bfcache not-restored reason (web.dev article). By adding the API, we would like to enable data gathering from the wild in addition to locally reproducing and testing bfcache.