Back/forward cache (bfcache)
The browser keeps a whole page ready in memory, so Back and Forward can restore it instantly with its state and scroll position intact.
See it
What it is
The back/forward cache, usually shortened to bfcache, keeps a complete page in memory when you navigate away. If you return with the browser's Back or Forward button, the browser can restore the DOM, JavaScript heap, and scroll position instead of rebuilding the page and repeating its network requests. The 'pageshow' event fires on restore, and 'event.persisted' tells you when bfcache was used.
Reach for it when repeat navigation inside a site feels slower than it should. You do not turn bfcache on with one API. You keep the page eligible by avoiding features that require it to be destroyed, then test a real Back and Forward trip in Chrome DevTools. In the field, PerformanceNavigationTiming.notRestoredReasons reports exactly which blocker kept a given navigation out of the cache.
Gotcha: 'load' does not run again after a bfcache restore, so code that refreshes stale prices, auth state, or timers only on 'load' can show old data. Listen for 'pageshow' as well. Avoid 'unload' handlers, use 'pagehide' for navigation cleanup, and pause work when the page is hidden instead of assuming it has been discarded.
Ask AI for it
Make this page eligible for the browser back/forward cache. Remove 'unload' listeners, move necessary navigation cleanup to 'pagehide', and add a 'pageshow' listener that checks 'event.persisted' before refreshing time-sensitive data. Pause timers, observers, and open work when 'document.visibilityState' becomes 'hidden', then resume them on 'pageshow'. Test the result with Chrome DevTools Application > Back/forward cache and verify that a Back and Forward round trip restores the page, form state, and scroll position without a new document request. Then log PerformanceNavigationTiming.notRestoredReasons from real sessions so regressions show up as named blockers rather than a vague slowdown.