Instant Back/Forward

Installation from within WordPress

1. 01Visit Plugins > Add New in the WordPress Admin.
2. 02Search for Instant Back/Forward .
3. 03Install and activate the Instant Back/Forward plugin.
4. 04Log out of WordPress and log back in with the “Remember Me” checkbox checked.

You may also install and update via Git Updater using the plugin’s GitHub URL .

Manual Installation

1. 05Download the plugin ZIP from WordPress.org. (You may also download a development ZIP from GitHub ; alternatively, if you have a local clone of the repo , run npm run plugin-zip .)
2. 06Visit Plugins > Add New Plugin in the WordPress Admin.
3. 07Click Upload Plugin .
4. 08Select the nocache-bfcache.zip file on your system from step 1 and click Install Now .
5. 09Click the Activate Plugin button.
6. 10Log out of WordPress and log back in with the “Remember Me” checkbox checked.

What about stale content being served in cached pages?

Please see the Stale Content in Page Caches section of the above blog post.

What WordPress core tickets does this plugin relate to?

The functionality in this plugin is proposed for WordPress core in Trac ticket #63636 : Enable instant page navigations from browser history via bfcache when sending “nocache” headers.

Other relevant core tickets that this revisits:

• #21938 : Add “no-store” to Cache-Control header to prevent history caching of admin resources
• #55491 : Replace unload event handlers from core
• #57627 : The Cache-Control header for logged-in pages should include private
• #61942 : Add “no-store” to Cache-Control header to prevent unexpected cache behavior

Why not use the Clear-Site-Data header?

Instead of using the pageshow event handler, an alternative method to evict pages from bfcache is to send the Clear-Site-Data: "cache" at logout. Per MDN , this header “sends a signal to the client that it should remove all browsing data of certain types (cookies, storage, cache) associated with the requesting website.” This header is supposedly supported by 91%+ of users according to Can I Use… and it is “Baseline 2023 Newly available” but with an asterisk. In testing, only Chromium-based browsers (e.g. Chrome and Edge) seem to evict pages from bfcache when this header is sent, but there is currently a bug ( 40233601 ) where responses with this header can take 10-30 seconds to load. Furthermore, Firefox does not currently evict pages from bfcache with this header, but like Chromium browsers, it does evict pages from HTTP cache, meaning authenticated pages will not be accessible when reopening closed browser tabs. Safari, however, does not seem to evict pages from either bfcache or the HTTP cache. Lastly, Clear-Site-Data only works in a secure context (i.e. over HTTPS), meaning insecure sites still on HTTP would have yet another concern.

For all these reasons, Clear-Site-Data is not yet a reliable method to invalidate pages from bfcache. Hopefully the Chromium bug will be fixed in the near future.

The Clear-Site-Data header was also mentioned in Trac tickets #49258 and #57627 .

Why is bfcache working in Chrome even though my site is using Cache-Control: no-store?

Chrome may even now store pages served with no-store in bfcache, although there are still failure scenarios in which bfcache will still be blocked. These can be observed in the “Back/forward cache” panel in the Application tab of Chrome DevTools, for example:

• JsNetworkRequestReceivedCacheControlNoStoreResource : JavaScript on a page makes a request to a resource served with the no-store directive (e.g. REST API or admin-ajax).
• CacheControlNoStoreCookieModified : JavaScript on a page modifies cookies.

These scenarios happen frequently when browsing the WP Admin, and they occur frequently on the frontend when using plugins like WooCommerce or BuddyPress. Such bfcache failures can also occur when not being logged in to WordPress, as it can happen whenever a site calls nocache_headers() . For example, WooCommerce currently calls nocache_headers() when an unauthenticated user is on the Cart, Checkout, or My Account pages (but see woocommerce#58445 which has been merged to remove this as of v10.1). These failure scenarios do not occur when the no-store directive is omitted from the Cache-Control header.

What is preventing bfcache from working?

See the Back/forward cache article on web.dev for reasons why bfcache may be blocked. See also the list of blocking reasons on MDN. See also the YouTube video on Debugging bfcache, make your page load instantly .

If you can identify the plugin or theme which is setting Cache-Control: no-store or doing something else that blocks bfcache (like adding an unload event handler), please report the issue to the respective plugin/theme support forum.

The Performance Lab plugin also includes a Site Health test for whether the server is sending the Cache-Control: no-store header.

Why is bfcache not working on my site hosted by Pantheon?

Pantheon sites have a must-use plugin which includes some Page Cache functionality . When a user is logged in, it is currently sending a Cache-Control: no-cache, no-store, must-revalidate response header. This prevents bfcache from working. A pull request has been opened to fix this, but in the meantime you may work around the issue by preventing this header from being sent with the following plugin code:

// Workaround for Pantheon MU plugin sending Cache-Control: no-store which prevents bfcache. // See https://github.com/pantheon-systems/pantheon-mu-plugin/pull/94 add_filter( 'pantheon_skip_cache_control', static function (): bool { return is_admin() || is_user_logged_in(); } );