Instant Back/Forward Navigations in WordPress  ## Metadata - Author: [[Weston Ruter]] - Full Title: Instant Back/Forward Navigations in WordPress - Category: #articles - Document Note: --- tags: - #wordpress - #webperformance - #userexperience Author: Weston Ruter Source: Weston Ruter's Blog Reference: https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/ date created: 2025-07-23 09:30 --- # Title: Instant Back/Forward Navigations in WordPress ## Table of Contents:  - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Ruter, Weston. "Instant Back/Forward Navigations in WordPress." Weston Ruter's Blog, July 23, 2025. https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/ ## 📝 Summary: This article explores implementing instant back and forward page navigations in WordPress to dramatically improve perceived user experience and site performance. Weston Ruter details leveraging modern browser APIs and progressive enhancement techniques to cache and preload pages, reducing the latency traditionally encountered during browser history navigation. The article discusses technical approaches, challenges, and possible WordPress-specific integration strategies to bring near-instant navigation speeds typical of Single Page Applications (SPAs) to traditional WordPress websites. ## 📖 Main Content: The author begins by contextualizing the problem: navigating back and forward using browser buttons often triggers full page reloads, leading to delays that hurt user experience. Instant navigation, where previously visited pages appear immediately, is a hallmark of SPAs but has been difficult to replicate in server-rendered sites like WordPress. Weston explores recent browser capabilities such as the Back-Forward Cache (bfcache), which preserves complete page state in memory. However, support and reliability issues still exist, especially for complex CMS-driven sites. To enhance this, he suggests combining bfcache with proactive page caching, preloading, and smart resource management. The article further details how WordPress could integrate these techniques. Potential solutions include hooking into page transitions, employing JavaScript to manage history state, and caching rendered pages client-side. Challenges such as invalidating caches on dynamic content, preserving form states, and handling third-party scripts are examined. Additionally, Weston emphasizes progressive enhancement, ensuring that users on older browsers or with JavaScript disabled still experience full functionality, albeit without instant navigation. Finally, the article hints at future possibilities for WordPress core or plugin ecosystems to standardize such performance improvements, encouraging community experimentation and collaboration. ### 🗒️ Notes - **Problem Statement:** - Traditional back/forward navigation in WordPress triggers full page reloads. - This causes latency and disrupts smooth UX, especially on slower networks. - **Browser Advances:** - Back-Forward Cache (bfcache) can instantaneously restore pages. - Limitations include inconsistent support and complexity with dynamic content. - **Enhancement Techniques:** - Combining bfcache with client-side caching to preload pages. - Using JavaScript to intercept navigation events and render cached content. - **WordPress-Specific Considerations:** - Dynamic content invalidation (comments, user data, widgets). - Managing form inputs and scroll restoration. - Handling third-party plugins and scripts that may not be cache-friendly. - **Implementation Ideas:** - Hook into WordPress lifecycle to detect page changes. - Use Service Workers or client-side caches for offline or instant loading. - Leverage REST API to update parts of the page dynamically. - **Progressive Enhancement:** - Ensure functionality degrades gracefully on unsupported browsers. - Users without JavaScript retain normal navigation. - **Community and Future:** - Potential for plugin development or core inclusion. - Encourages experimentation and sharing of implementation patterns. ## 📖 References: - Mozilla Developer Network. "Back-Forward Cache." https://developer.mozilla.org/en-US/docs/Web/Performance/Back-Forward_Cache - WordPress REST API Documentation. https://developer.wordpress.org/rest-api/ - Ruter, Weston. "Instant Back/Forward Navigations in WordPress." Weston Ruter's Blog. https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/ ## 🗣️ Paraphrase: 1. Original: "Back and forward buttons are fundamental navigation features, but in traditional websites, they cause full page reloads, which disrupt the user experience and slow interactions." Paraphrase: Navigating using the browser’s back and forward controls is essential, yet on conventional websites this action forces the entire page to reload, resulting in slower performance and a jarring experience for users. 2. Original: "Combining browser-level caching like bfcache with proactive page caching and JavaScript-controlled history management can enable near-instant navigations in WordPress sites." Paraphrase: By integrating native browser caching mechanisms such as bfcache with preemptive page caching strategies and JavaScript-managed navigation history, WordPress websites can achieve navigation speeds approaching instantaneous transitions. ## 📰 Newsletter: 🚀 **Boost Your WordPress Site Speed with Instant Back/Forward Navigation!** 🚀 Hey WordPress lovers! Have you ever felt that lag when clicking your browser’s back or forward button? Weston Ruter has some exciting insights on how to make these navigations *instant* on WordPress sites — yes, just like those slick Single Page Apps! By leveraging modern browser features like the Back-Forward Cache, coupled with smart caching and JavaScript tricks, you can significantly enhance your visitors’ browsing experience. This approach minimizes annoying reloads and keeps users flowing through your content effortlessly. If you’re passionate about WordPress performance or developing cutting-edge themes and plugins, this deep dive is a must-read. It outlines the challenges and offers practical paths forward to supercharge site responsiveness. Dive into Weston’s detailed exploration here: [Instant Back/Forward Navigations in WordPress](https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/) Stay speedy! ⚡️ ## ✅ Action Items: - Review current site navigation patterns to identify latency during back/forward actions. - Experiment with browser bfcache support across major browsers in your WordPress environments. - Prototype JavaScript interception of navigation events to cache and preload pages. - Assess compatibility of existing plugins and themes with bfcache and client-side caching. - Collaborate with WordPress core and plugin developers to explore integration strategies. - Develop educational content or workshops explaining instant navigation benefits and implementation. - Advocate for progressive enhancement to maintain accessibility and graceful degradation. - Align these technical improvements with your role as Developer Advocate to champion superior user experience and innovation in the WordPress ecosystem. ## 🧪 Hypotheses: - Integrating bfcache with client-side caching can reduce back/forward navigation latency by over 90% in WordPress sites. - WordPress sites employing instant navigation techniques will see increased session duration and lower bounce rates. - JavaScript-managed history and caching can maintain dynamic content accuracy without compromising instant loading. - User satisfaction scores w - Summary: The new No-cache BFCache plugin enables instant back/forward navigations, particularly while logged in. - URL: https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/  July 23, 2025 [WordPress](https://weston.ruter.net/category/wordpress/) The new [**No-cache BFCache**](https://wordpress.org/plugins/nocache-bfcache/) plugin enables instant back/forward navigations, particularly while logged in. See [demos below](https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/#demos) for the impact this has on browsing. The speed of page navigations in WordPress has seen a big boost in 6.8 with the introduction of [Speculative Loading](https://make.wordpress.org/core/2025/03/06/speculative-loading-in-6-8/). When paired with the original [feature plugin](https://wordpress.org/plugins/speculation-rules/), site visitors can experience instant page navigations thanks to its opt-ins for prerendering and “moderate eagerness”. However, WordPress does not enable such instant navigations by default. WordPress core must take a conservative approach since prerendering may cause compatibility problems, like with analytics or ads. There is also a sustainability concern with moderate prerendering since a user may momentarily hover over a link but not intend to follow it at all; this results in an unused prerender, which can waste a user’s bandwidth (and CPU to a limited extent) as well as increase the load on the web server (which can be problematic on shared hosts without page caching). Furthermore, even when prerendering is enabled, not all visitors may be able to experience instant page loads because: 1. Moderate eagerness is limited on mobile devices (where there is no hover heuristic on touch screens). 2. Speculative Loading is not enabled by default when a user is logged in. 3. The Speculation Rules API is currently only [supported](https://caniuse.com/mdn-html_elements_script_type_speculationrules) in Chromium, leaving Safari and Firefox users out. Nevertheless, there is a much older web platform technology that enables “prerendering” *and* which is supported in all browsers: the [back/forward cache](https://developer.mozilla.org/en-US/docs/Glossary/bfcache) (bfcache). This instant page navigation involves no network traffic and no CPU load. Previously visited pages are stored in memory as a snapshot with their entire state so that they can be restored instantly. Navigating to pages stored in bfcache is as fast as switching open browser tabs. Back/forward history navigations are very common, as according to the [web.dev article](https://web.dev/articles/bfcache) on bfcache: > Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day! > > Also learn more via the [following video](https://youtu.be/Y2IVv5KnrmI): While Speculative Loading enables prerendering, bfcache involves “pre*vious*-rendering”. The good news is that 84% of WordPress origins in [HTTP Archive](https://httparchive.org/) are already bfcache-eligible (based on [this query](https://gist.github.com/gilbertococchi/083c1516149cf5f70b103451d1790cbc) from [Gilberto Cocchi](https://github.com/gilbertococchi)). **However, the most frequent user of your site may still not be able to experience instant page navigations via bfcache: *you!*** While browsing around the WP Admin and navigating the frontend of your site, the pages most likely aren’t eligible for bfcache due to various [blocking reasons](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons#blocking_reasons). This sluggish experience extends not only to administrators but also to users of sites which require authentication, including e-commerce (e.g. WooCommerce), social (e.g. BuddyPress), and any membership sites. The 84% metric above doesn’t take into account these types of WordPress sites since HTTP Archive exclusively crawls public URLs without authentication. Users browsing WordPress sites on shared hosts or when on a slow connection will be especially frustrated by slow back/forward navigations. Enabling instant back/forward navigations will not only make your users happier (especially you), but it can also improve your CWV passing rate [in CrUX](https://developer.chrome.com/blog/crux-navigation-types). I’ve been on a mission to bring back bfcache (or rather to bring it forward). This all goes back two years ago when I was collaborating on [#55491](https://core.trac.wordpress.org/ticket/55491) to eliminate the use of the [deprecated](https://developer.chrome.com/docs/web-platform/deprecating-unload) `unload` event handler in WordPress core. Not only does this event fire unreliably, but it also has the side effect of making a page [ineligible for bfcache](https://web.dev/articles/bfcache#never-use-the-unload-event) via the “[unload-listener](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons#unload-listener)” blocking reason. I had [queried](https://github.com/GoogleChromeLabs/wpp-research/pull/75) HTTP Archive myself at the time, and I found it to be the second most common blocking reason. So in [r56809](https://core.trac.wordpress.org/changeset/56809) we eliminated all uses of `unload`, including from: However, even with the use of `unload` eliminated, I was confused why I wasn’t finding pages to be eligible for bfcache in my testing. (The removal of `unload` in core likely didn’t make a dent in bfcache eligibility in HTTP Archive since only [0.25%](https://github.com/GoogleChromeLabs/wpp-research/pull/75#:~:text=Lastly%2C%20in%20heartbeat%2Dscript%2Dpresence.sql%20I%20check%20to%20see%20how%20common%20the%20Heartbeat%20script%20actually%20is%3A) of unauthenticated pages had the Heartbeat API present.) It turns out that several weeks before I started working on this, a [commit](https://core.trac.wordpress.org/changeset/55968) had landed which *intentionally* broke browser page caching (both bfcache and HTTP cache): the `no-store` directive was added to the `Cache-Control` response header for logged-in users. (Specifically, this was added to the `[wp\_get\_nocache\_headers()](https://developer.wordpress.org/reference/functions/wp_get_nocache_headers/)` function.) This introduced the “[response-cache-control-no-store](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons#response-cache-control-no-store)” bfcache blocking reason, which was actually the [most common reason for ineligibility](https://github.com/GoogleChromeLabs/wpp-research/pull/75#:~:text=Pages%20whose%20main%20resource%20has%20cache%2Dcontrol%3Ano%2Dstore%20cannot%20enter%20back/forward%20cache.), just above `unload` in my HTTP Archive query. The reason for adding this is found in [#21938](https://core.trac.wordpress.org/ticket/21938) which proposed adding the `no-store` directive in order to explicitly *disable* caching so that authenticated pages do not get stored in the browser cache. This was followed up with [#61942](https://core.trac.wordpress.org/ticket/61942) to also send `no-store` on the frontend while a user is logged in. The rationale for this is rooted in privacy, per the commit message: > The intention behind this change is to prevent sensitive data in responses for logged in users being cached and available to others, for example via the browser history after the user logs out. > > Consider an administrator who is logged in to WordPress on a shared computer and is working on something sensitive, like managing API keys on an admin screen. A malicious person could navigate back to that admin screen via the back button after the user had logged out. Nevertheless, the “bad guy” will need to act fast because a browser won’t store cached pages indefinitely; Chrome, for example, holds onto pages in bfcache for [10 minutes](https://developer.chrome.com/docs/web-platform/bfcache-ccns#:~:text=The%20bfcache%20timeout%20for%20Cache%2DControl%3A%20no%2Dstore%20pages%20is%20also%20reduced%20to%203%20minutes%20(from%2010%20minutes%20used%20for%20pages%20which%20don%27t%20use%20Cache%2DControl%3A%20no%2Dstore)%20to%20further%20reduce%20risk.). (Tip: When using a shared computer, always exit the browser after logging out of all sites when ending work.) So while `no-store` here does improve privacy, it does so at the expense of the user experience by degrading the performance of back/forward navigations. Even when pages aren’t eligible for bfcache, removing `no-store` still improves back/forward navigation performance since pages can be served from the browser’s HTTP cache (although the DOM has to be re-built and scripts have to be re-executed). **Surely there must be a way to preserve privacy and promote performance together.** It’s important to note that the `no-store` directive not only prevents pages from being cached by the browser, but it also preserves privacy by preventing proxies from caching pages, per [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control#no-store): > The `no-store` response directive indicates that any caches of any kind (private or shared) should not store this response. > > Keeping authenticated pages out of page caches prevents embarrassing scenarios like serving a user the shopping cart page for another user. Nevertheless, there is a more tailored `Cache-Control` mechanism for this purpose: the `private` directive. Again, per [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control#private): > The private response directive indicates that the response can be stored only in a private cache (e.g., local caches in browsers). ¶ You should add the private directive for user-personalized content, especially for responses received after login and for sessions managed via cookies. ¶ If you forget to add private to a response with personalized content, then that response can be stored in a shared cache and end up being reused for multiple users, which can cause personal information to leak. > > This is what was originally requested in [#57627](https://core.trac.wordpress.org/ticket/57627), but both `private` and `no-store` were added together, with the [commit](https://core.trac.wordpress.org/changeset/55968) message reasoning: > The `private` directive complements the `no-store` directive by specifying that the response contains private information that should not be stored in a public cache. Some proxy caches may ignore the `no-store` directive but respect the `private` directive, thus it is included. > > So how can the `private` directive be retained for proxies, while removing the `no-store` directive so that a user can benefit from browser caching but not at the expense of privacy? In order to omit the `no-store` directive and enable instant back/forward navigations while preserving privacy, a way is needed to evict pages from the browser cache when a user logs out. In my research, there are three mechanisms to do this, with various degrees of browser support. The most straightforward mechanism to invalidate pages from bfcache would at first seem to be the `Clear-Site-Data` HTTP response header. This is supposedly Baseline 2023 Newly Available, but there is an asterisk: “Some parts of this feature may have varying levels of support.” Per [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data), 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.” In fact, the `cache` directive for this header seems to be exactly what is needed, as it even [explicitly calls](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data#cache) out bfcache: > The server signals that the client should remove locally cached data (the browser cache, see [HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching)) for the origin of the response URL. Depending on the browser, this might also clear out things like pre-rendered pages, [backwards-forwards cache](https://developer.mozilla.org/en-US/docs/Glossary/bfcache), script caches, WebGL shader caches, or address bar suggestions. > > However, note the word “might”. In my testing, sending this header does currently evict pages from bfcache in Chrome. But, there is an [open spec question](https://github.com/w3c/webappsec-clear-site-data/issues/73) for whether Clear-Site-Data should clear bfcache; it mentions [dropping](https://github.com/w3c/webappsec-clear-site-data/issues/68) the `cache` directive entirely, and it suggests that a different `executionContexts` directive may be more appropriate (but its browser support is even worse and it may be [dropped](https://github.com/w3c/webappsec-clear-site-data/issues/59) from the spec). Firefox [dropped support](https://bugzilla.mozilla.org/show_bug.cgi?id=1671182) for the `cache` directive but then [restored](https://bugzilla.mozilla.org/show_bug.cgi?id=1930500) it, although in testing it seems Firefox only evicts pages from the HTTP cache and not from bfcache. Finally, Safari doesn’t seem to evict pages from either the HTTP cache or bfcache when this header is sent. When/if browser support for this is improved, implementing eviction of pages from browser caches could be as simple as: Ultimately, while this header seems to be tailor-made for evicting pages from browser caches, it cannot be relied on since it is clearly not widely available in Baseline, and not even “newly available” either. There is also a Chromium bug ([40233601](https://issues.chromium.org/issues/40233601)) where sending this header can greatly delay page response times, possibly causing a logout link to take half a minute to respond. The final mark against `Clear-Site-Data` is that the header requires a secure context (HTTPS), so the WordPress sites still on HTTP could not evict pages from browser caches using this header (although privacy could be the last of their concerns at this point). So to preserve privacy, another browser page cache invalidation method is currently needed. Going back to the aforementioned bfcache [blocking reasons](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons#blocking_reasons), one of them is “[broadcastchannel-message](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Monitoring_bfcache_blocking_reasons#broadcastchannel-message)”: > While the page was stored in back/forward cache, a [BroadcastChannel](https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel) connection on the page received a message to trigger a [message](https://developer.mozilla.org/en-US/docs/Web/API/MessageEvent) event. > > I went down a rabbit hole with this one, thinking I could leverage this blocking reason as a bfcache eviction mechanism. In my discarded implementation, all authenticated pages include a script which listens to a broadcast channel such as “auth\_change”. Then, to evict authenticated pages from bfcache upon a successful logout (or logging in as another user), a script can be included on the page which simply broadcasts an arbitrary message to this same “auth\_change” broadcast channel. This causes the eviction of any authenticated pages in bfcache which are listening to messages from this broadcast channel. I was seeing very promising results with this approach, where pages were being successfully evicted from bfcache in Chromium (Chrome/Edge) and Firefox. Nevertheless, eviction was not happening in Safari, which apparently has not yet implemented this blocking reason. *However*, this approach fell apart once I closed DevTools. Normally when DevTools is open I have “Disable cache” checked in the Network panel. This disables the HTTP cache, but not the bfcache. What I would see then is if I navigated around the WP Admin and then logged out in a second tab, hitting the back button in the first tab would immediately take me to the login screen. This is exactly what I wanted. However, once I closed DevTools, I started seeing pages served from the browser’s HTTP cache when navigating back/forward. Because the `no-store` directive is removed, this means the browser may actually serve pages from HTTP cache when navigating back/forward, even when the `Cache-Control` header has `no-cache`, `must-revalidate`, and `max-age=0`. And here, when the user logged out, they shouldn’t be served from either HTTP cache or bfcache to preserve privacy. So this was not a viable approach in the end. Ultimately, the most reliable solution I’ve found to invalidate pages from both bfcache and the HTTP cache is to do so just-in-time with JavaScript: When a page is restored from a browser cache and it is determined to be stale, the page contents are wiped and the page is reloaded. This involves the creation of a new session token when the user authenticates. This session token is served in the HTML with each authenticated page, and it is also set as a `wordpress_​bfcache_​session_​{COOKIEHASH}` cookie which can be read by JavaScript. When a user logs out, this session token cookie is cleared. Whenever a page is loaded, the session token in the HTML is compared with the current session token in the cookie. When they don’t match, then the page is invalidated. If a page is served from bfcache, then the `pageshow` event (with `persisted` true) is used to do this check; if a page is served from the HTTP cache, then the check is done when the script module is executed. If the user had logged out, then reloading the page will take them to the login screen which, after authenticating, will redirect them back to the page they had been on. As this page cache invalidation mechanism depends on JavaScript, scripting must be enabled to be eligible to omit the `no-store` directive from the `Cache-Control` header. This JavaScript detection can be done when the user submits the login form. This implementation has been made available in a new plugin: **No-cache BFCache**. It is available [on WordPress.org](https://wordpress.org/plugins/nocache-bfcache/) and [on GitHub](https://github.com/westonruter/nocache-bfcache/). This is a feature plugin to implement [#63636](https://core.trac.wordpress.org/ticket/63636) in WordPress core. In the following demos, I have Slow 4G network emulation enabled along with CPU throttling. This is in order to better simulate what an average user may experience when navigating, such as on a mid-range device potentially with a WordPress site on a shared host. After navigating from the Dashboard to the posts list table and then opening a post to edit, you can see the difference in speed navigating back and forth through the browser history: Here you can see me draft a message in a BuddyPress activity update. Then I navigate to another URL, and then I go back and forward: 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. 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. WooCommerce has been serving pages with `no-store` even for unauthenticated users on its Cart, Checkout, and Account pages. This slowed down navigating a store, even though Woo already implements support for ensuring a cart is up-to-date via the `pageshow` event (with `persisted` true). The lack of bfcache means not only that navigating back to the cart is much slower than it needs to be, but there can also be data loss, for example an entered coupon but accidentally not applied. In PR [#58445](https://github.com/woocommerce/woocommerce/pull/58445) the sending of `no-store` was removed. This is slated to be part of v10.1. See [before/after demo videos](https://github.com/woocommerce/woocommerce/pull/58445#issuecomment-3014404754). Similarly, in Jetpack certain admin screens are sending `no-store` which slow down back/forward navigations. Pending PR [#44322](https://github.com/Automattic/jetpack/pull/44322) removes this and greatly speeds up navigating to/from Jetpack admin screens, as seen in the [demo videos](https://github.com/Automattic/jetpack/pull/44322#:~:text=no%2Dstore.-,Demo%20Video,-Compare%20navigating%20back). Sometimes the instantaneous navigations enabled by bfcache (and prerendering in Speculative Loading) can be a bit jarring, since pages load faster than expected. So the No-cache BFCache pairs well with the [View Transitions](https://wordpress.org/plugins/view-transitions/) plugin which now features an Admin View Transitions opt-in. This helps smooth the overall experience. Special thanks to [Kinsta](https://kinsta.com/) for [sponsoring](https://github.com/sponsors/westonruter) part of my time contributing to WordPress while I’ve been [between full time roles](https://weston.ruter.net/2025/05/14/a-decade-as-a-core-committer-my-wordpress-contribution-history/). I also [discussed](https://www.youtube.com/watch?v=d_I_JsFi2M0&t=842s) this bfcache project in my “[From Cassette Tapes to Core Commits: Weston Ruter’s WordPress Journey](https://youtu.be/d_I_JsFi2M0)” interview with [Roger Williams](https://www.linkedin.com/in/rogerwilliamsmedia?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BSVYGJ1iQReyyHVN4aXnkag%3D%3D) last week. Where I’ve shared this, if you want to boost:, Instant Back/Forward Navigations in WordPress, Weston Ruter, 01k0vp82jhcfa83t8h9gfw3z59.