Back restores an old page: refresh the right state without breaking history

Understand what came back

The back/forward cache, or BFCache, can retain the whole document, including its JavaScript state, while the visitor navigates away. Restoring that document differs from fetching HTML through an HTTP cache. A CDN purge does not rewrite a document already preserved in browser memory.

Suppose a fictional shop displays two notebooks in a cart. The visitor opens another page, changes the cart there, then goes Back. Restoring the earlier cart panel can bring back its old number without a fresh request. The number is stale; the browser has not necessarily served the wrong user’s response or ignored a server update.

First distinguish browser history from a site’s own Back link. An app using client-side routing can restore its own state during a soft navigation. BFCache applies to browser-managed document navigation; a similar-looking route change inside an SPA needs its router and data lifecycle investigated separately.

Build a repeatable history journey

Choose synthetic accounts or harmless cart items. Record the starting page, action, destination, state change made while away, and exact Back or Forward operation. Keep a screenshot of the stale region, but also inspect whether a relevant request was made on return.

Repeat the journey after a normal reload. If the reload is correct while Back is stale, that narrows the investigation. It does not identify BFCache by itself: application memory, form restoration and other caches can create related symptoms.

For the notebook example, write an acceptance rule before changing code: returning to the page must show the current server cart, retain a valid unsent delivery note, and avoid adding an item twice. Those are three separate outcomes. A full reload might repair the first while failing the other two.

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.info('Restored document from history cache');
  }
});

Use browser diagnostics without designing around one result

The Chrome DevTools BFCache panel can run a navigation test and explain reasons a page is not restored. It is useful for distinguishing a real restoration from a new document load. Record the browser version and the tested route.

Test other supported browsers and a normal visitor profile too. A successful laboratory return does not guarantee retention after a long interval, on a memory-constrained device or after another tab changes the session. Conversely, a development-only blocker does not prove that production never restores the page.

Keep useful lifecycle diagnostics separate from unrelated console warnings. Our Console and Network guide explains how to correlate an action, exception and response without exposing session secrets.

Refresh facts according to their risk

Classify the restored regions. Static article text usually needs no immediate request. A cart count or availability panel may need revalidation. An account page can require current session and authorization confirmation before sensitive information or actions remain available.

For the fictional cart, request the current cart through the application’s supported read endpoint, then reconcile its quantity and price display. Keep the unsent delivery note separate unless the server rejects its context. If the refreshed product is unavailable, explain that fact beside the affected item rather than wiping every field.

Handle loading, failed refresh and a changed account explicitly. Do not silently leave an old “ready to pay” button active when the application cannot confirm the order facts it depends on. An understandable retry or sign-in route is better than a spinner that never tells the visitor whether their work survived.

Avoid races when several restorations or refreshes overlap. The maintainer should ensure an older response cannot overwrite a newer account or cart context. That is application state management, not a feature pageshow supplies automatically.

Do not use no-store as a universal BFCache switch

HTTP Cache-Control and document history restoration have different purposes. Chrome’s current no-store guidance describes conditional BFCache support for certain pages carrying that directive. The rollout means an old rule of thumb that no-store always prevents restoration is unreliable.

Keep the response’s HTTP privacy policy correct for its contents. Do not remove no-store from sensitive responses just to gain eligibility, and do not assume adding it supplies a complete logout or account-switch design. Browser-specific safeguards are not a replacement for the application’s access controls.

If returning after sign-out can expose confidential content, treat the display policy as a security requirement and have the responsible maintainer review it. A refresh initiated only after pageshow may allow previously rendered content to appear briefly; it is not, by itself, proof that this exposure has been prevented.

Preserve history instead of forcing every return to reload

Unconditional reload handlers discard useful scroll, selections and unfinished input. They can also trigger repeated reloads when navigation and application listeners interact. Prefer scoped reconciliation of the regions that need it, with a clear pending state.

Do not add an unload listener simply to make a page ineligible. The documented lifecycle approach uses page transition events, and unload is unreliable as a clean-up mechanism. Resource ownership and sensitive-display decisions need a deliberate design rather than an eligibility accident.

A visitor may return to a form whose validation errors have changed. Preserve valid answers, update stale options, and explain what must be corrected. If a session genuinely expired, tell the visitor what can be retained before sending them through authentication again.