Back-Forward Cache and Restored State

Working case

Reviewer 29 leaves case 47 open, signs out in another tab, and later presses Back. The browser can restore the prior page instantly with its old controls and text. The application must not treat that preserved heap as fresh authorization. On pageshow after restoration, clear or lock sensitive actions, check the current session and case version, and replace the old view if access was removed. The same path should handle another reviewer resolving the case while this tab was away. A fast restoration is useful only if it does not present stale authority as a current fact.

Implementation boundary

function shouldRecheckOnShow(event, lastCheckedAt, now) {
  return event.persisted || now - lastCheckedAt > 30000;
}
console.log(shouldRecheckOnShow({ persisted: true }, 1000, 2000));
// Output: true

The predicate is a policy hook, not the whole security boundary: every server action still checks the current session and record permission. In a browser, register pageshow once at the page owner, and revalidate volatile queries when its persisted property is true. If the page was merely hidden and later shown, a separate visibility-based freshness policy may apply. Do not assume a bfcache restore fires DOMContentLoaded again. Test restored content and controls after sign-out, permission change, and status change; browsers differ in eligibility, so include an ordinary reload comparison.

Cost and boundaries

A restore can make navigation nearly immediate, but a revalidation adds one or more network reads and can alter the view after it appears. Checking every restored field is expensive; prioritize permission and volatile data. Holding a whole page in browser memory also has a cost, and the browser decides whether to retain it. An unload handler may prevent the optimization in some browsers, so avoid it unless its work is truly necessary. Correctness still relies on server checks even if no restore occurs.

Failure trace

A page assumes mount means fresh data and never listens for pageshow. After a sign-out in another tab, Back restores the old action button; the next write fails, but the screen misleadingly claims the action is available. Another team adds unload cleanup and unintentionally loses fast restores. Make restored state explicit, lock or refresh volatile actions, and move cleanup to pagehide or route ownership where appropriate. Verify both success and denial responses while the old page is visible.

Verification

• Back after sign-out cannot leave active private controls.
• A changed case version is reconciled after restoration.
• The page works whether or not the browser retains it in memory.

Practice drill

Open case 47, leave to another route, change its status in a second tab, and return with Back. Record whether pageshow persisted is true and whether the displayed status is reconciled. Repeat after sign-out and after the user's access to the case is removed. Compare normal reload with history restoration. Add and remove an unload listener in a controlled experiment, then inspect restore eligibility and behavior rather than assuming the browser will always cache the page.

Decision note

Treat a restored page as a preserved snapshot and revalidate the volatile authority it displays.

Common Mistakes

• Assuming load handlers run again on history restoration.
• Using the old DOM as proof of current permission.
• Adding unload cleanup without measuring its lifecycle effect.

Connected lessons

Navigation, History, and Page Lifecycle; URL State and History Entry Contracts; Route Scroll and Focus Restoration; Navigation Prefetch and Private Data Budget; Sessions and CSRF: keep identity on the server; Client Cache Keys and Invalidation; Browser Memory and Resource Lifecycles.

Apply and check

Build Project: history-safe review journey and review Web Development: navigation and delivery decisions quiz.