← Concepts

阅读中文版本

Back/Forward Cache

The back/forward cache stores a fully live page snapshot on navigation so the back button restores it instantly, unless the page holds unload handlers, open sockets, or other disqualifying state.

browser

Definition

The bfcache is a browser in-memory snapshot of a page kept after navigating away, including DOM, JavaScript heap, and scroll position. Returning via back or forward restores the snapshot without reload, re-execution, or refetch. Pages are evicted or never cached when they use APIs incompatible with freezing, such as unload listeners or active WebSocket state.

Context and scope

Tuned for news, docs, and e-commerce browsing where back navigation is frequent. Also the reason unload handlers silently destroy instant-back UX and why pages need pageshow handlers to refresh stale data.

Common misconceptions

  • The bfcache is a screenshot — it is a full live heap snapshot; JavaScript state, timers, and DOM all resume
  • Back always reloads from network — a bfcache hit restores instantly without a single request
  • Only performance-minded teams opt in — eligibility is automatic; your job is to stop disqualifying yourself

Anti-patterns

  • Registering unload event handlers, the classic bfcache disqualifier, and losing instant back for every user
  • Keeping WebSockets and long timers alive without handling pagehide freeze semantics
  • Restoring a cached page with stale time-sensitive data because pageshow was never wired to refresh state

Related concepts

Related examples

Authoritative source

https://web.dev/articles/bfcache

What it is

Navigating away normally destroys the page. With bfcache, the browser freezes the entire page — DOM, heap, media state — and restores it on back or forward navigation in milliseconds. To the user, the previous page never left.

How it works

The page enters the cache on navigation; a restore triggers pageshow with persisted true. Disqualifiers include unload handlers in most engines, IndexedDB open transactions, open WebSocket or WebRTC state in some cases, and pages in iframes with cache-hostile headers. Cache-Control no-store on the main document also blocks entry in several implementations.

When to care

Any content site where users oscillate between listing and detail pages. Instrument pageshow to detect hit rates, replace unload with pagehide and visibilitychange, and refresh volatile UI such as timers and carts on restore.

Pitfalls

Restored pages resume scripts mid-thought: long-polling requests may be dead, cached auth state may be stale. Ad viewability and analytics need restore-aware event handling to avoid double counting or missing impressions. Test with browser flags that surface eviction reasons.