Back & forward cache
This filter works with the Time to First Byte metric
Browsers will attempt to create a snapshot of the state of a page when a user is navigating away from that page. This could either be navigating to another page within the same domain or a completely different domain.
When a user is navigating back using the back and forward buttons in their browser, a browser could then be able to present that same page from its snapshots. This typically results in a 0ms TTFB, very low FCP and LCP, no new lay-out shifts (CLS) and JavaScript state being restored. In other words, the experience will be instant.
Reasons for not restoring a page from the bfcache
However, there could be reasons why a browser was not able to create a snapshot. RUMvision is able to distinguish back forward attempts where the browser was and was not able to re-use a snapshot, both leading to different metrics.
Use our navigation type dimension to be able to spot the amount of missed bfcache opportunities.
Not restored reasons API
When enabled in your advanced cofiguration settings, we're also able to collect reasons why a page could not be restored from the cache by using the not restored reason (NNR) API.
A list of reasons is as follows:
- masked
The reason is masked either because the cross-origin iframes in the frame tree have blocking reasons, or because the main frame has blocked with browser internal reasons (e.g. implementation details) - parser-aborted
While loading the page, parsing was aborted and was incomplete. - navigation-failure
Loading the page resulted in error. - websocket
There were open WebSocket connections upon leaving the page. - weblock
There were held WebLocks upon leaving the page. - fetch
Fetch was initiated upon leaving the page.
Reason text is liable to change as more reasons are added and deleted, or to make the reason more obvious. For example,
developer.chrome.comunload-listener
shows asunload-handler
in Chrome 123.
Reporting the exact frame
If a specific window other than the current window was responsible for blocking the bfcache, we will report that too. It will be collected together with id, name or URL of the (i)frame that prevented a page from being served from the browser's bfcache.
For privacy reasons, the exception here is the cross-origin iframes. The NRR API will then report 'masked' for the outermost main frame.