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, unload-listener shows as unload-handler in Chrome 123.

developer.chrome.com

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.