Instant Back/Forward for WordPress

Also learn more via the following video:

Normally, WordPress sends a Cache-Control header with the no-store directive when a user is logged in. This has the effect of breaking the browser’s bfcache, which means that navigating back or forward in the browser requires the pages to be re-fetched from the server and for any JavaScript on the page to re-execute. The result can be a sluggish navigation experience not only when navigating around the WP Admin (see Jetpack demo video and demo video below) but also when navigating around the frontend of a site. Furthermore, the lack of bfcache can cause data loss when data has been entered via a JavaScript-built UI since this state is lost when a page is not restored via bfcache (see WooCommerce demo video and demo video below).

The reason why the no-store directive was added in the first place was due to a privacy concern where an authenticated user may log out of WordPress, only for another person to access the computer and click the back button to view the contents of the authenticated page loaded from bfcache or the HTTP cache. (See #21938.) In practice this issue depends on the user being on a shared computer who didn’t exit the browser, and it requires the malicious user to act soon before the page is evicted from bfcache (e.g. Chrome as a 10-minute timeout).

To address this privacy concern, a safeguard is in place to protect against restoring pages from bfcache and the HTTP cache after the user has logged out:

When authenticating to WordPress, a “bfcache session token” cookie is set along with the other authentication cookies. This cookie is not HTTP-only so that it can be read in JavaScript; it is a random string not used for any other purpose. When an authenticated page is served, this bfcache session token is included in the HTML as well as a script which reads the value of this cookie. When a user navigates away from the page and then navigates back to it, a script on the page checks if the current session token in the cookie matches the initial session token sent with the page. If they do not match (e.g. because the user has logged out or another user has logged in), then the contents of the page are cleared and the page is reloaded so that the contents are not available.

Since JavaScript is required to invalidate cached pages, the login form is extended to pass along whether scripting is enabled. Only when JS is enabled will the no-store directive be omitted from the Cache-Control response header. This ensures that users with JavaScript turned off will retain the privacy protection after logging out. Lastly, no-store is also only omitted if the user checked the “Remember Me” checkbox on the login form. Since it is highly unlikely a user on a shared computer would have checked this checkbox, this provides yet an additional safeguard (which may in the end prove excessive). A ✨ emoji is displayed next to the checkbox in a button that opens a popover that promotes the capability. If you want to opt out of this opt-in (and the sparkle) so that all logged-in users get bfcache, you can use the nocache_bfcache_use_remember_me_as_opt_in filter which you can use in a custom plugin or your theme:

add_filter( 'nocache_bfcache_use_remember_me_as_opt_in', '__return_false' ); When this plugin strips out the no-store directive, it also ensures that the private directive is sent in its place: “The private response directive indicates that the response can be stored only in a private cache (e.g., local caches in browsers).” WordPress is already sending private as of #57627. This directive ensures that proxies do not cache authenticated pages. In addition to ensuring private is present, this plugin also adds no-cache, max-age=0, and must-revalidate while ensuring public is removed, all to further guard against any misconfigured proxy from caching the private response.

Demo: Navigating the WordPress Admin Without bfcache:

With bfcache:

Demo: Navigating the WordPress Frontend Without bfcache: The drafted BuddyPress activity update is lost when navigating away from the page before submitting. The activity feed and Tweet have to be reconstructed with each back/forward navigation.

With bfcache: The drafted BuddyPress activity update is preserved when navigating away from the page without submitting. The activity feed and Tweet do not have to be reconstructed when navigating to previously visited pages via the back/forward buttons.