Safari Back-Forward Cache Restores Stale DOM or Network State

When a user navigates away from a page and then returns using the back or forward button, Safari may restore the page from its Back‑Forward Cache (bfcache) instead of issuing a new document load. In some cases the restored DOM or network‑dependent state appears stale, showing values from the earlier visit rather than reflecting updates that should occur on each return. The bfcache restoration is heuristic and varies with Safari/WebKit version, page characteristics such as open IndexedDB connections, unload/beforeunload handlers, active fetch or stream operations, and memory‑pressure eviction, making the stale‑vs‑fresh behavior difficult to reproduce consistently. To isolate bfcache effects, HTTP caching and service workers must be disabled during testing.

What specific page conditions cause bfcache to restore stale state instead of revalidating the document? How can developers reliably distinguish a bfcache restore from a normal load using the pageshow/persisted and pagehide/persisted flags? Which Safari/WebKit versions exhibit this behavior and what version‑specific eligibility rules determine whether a page is cached or forced to reload?