A browser tab is not guaranteed to keep running just because it remains open. It may lose focus, become hidden, enter the back-forward cache, freeze to conserve resources, or be discarded under memory pressure. The Page Lifecycle API gives web applications a clearer model for these transitions so they can save important state, release scarce resources, and recover without surprising the user.
The goal is not to keep every page active forever. It is to make a page resilient when the browser responsibly reduces its work.
Pages move through distinct states
A visible page with input focus is active. A visible page without focus is passive. When its tab or browser is no longer visible, it becomes hidden. From there, the browser may freeze its task queues, place it in the back-forward cache, terminate it during navigation, or discard it under resource pressure.
These states reflect a simple reality: CPU time, memory, battery, and network capacity are shared. A background page should not compete with the experience the user is actively using. The Chrome Page Lifecycle API guide maps the states, events, and recommended behavior for each transition.
Visibility is the most dependable early signal
The visibilitychange event fires when document.visibilityState changes. When a document becomes hidden, it may be the last reliable moment to persist application state, pause nonessential work, and send final analytics through an appropriate delivery method. Mobile operating systems can end a backgrounded browser without later delivering an unload event.
That makes hidden state more useful than waiting for termination. Save small, durable state early and often. A writing tool should persist the draft before the page disappears; a media interface should decide whether playback belongs in the background; a dashboard should stop visual updates that nobody can see.
Freeze and resume require resource discipline
When a page freezes, freezable tasks in its queues stop running. Open IndexedDB transactions, Web Locks, network connections, or polling loops can interfere with other tabs or prevent clean lifecycle behavior. A freeze handler should release resources that another context may need and ensure that durable state is already written.
On resume, code should revalidate assumptions rather than continuing blindly. Data may be stale, authentication may have changed, and timers may have missed long intervals. Refresh only what matters to the visible interface. This pairs naturally with the coordination techniques in our Web Locks API guide.
Back-forward cache changes navigation
Browsers can preserve a page in the back-forward cache, often called bfcache, so returning with the Back or Forward button feels instant. The pagehide event’s persisted property indicates whether the page is being cached. When pageshow later arrives with persisted set to true, the page was restored rather than loaded from scratch.
This means initialization code must distinguish a fresh load from a restored document. Avoid unconditional unload listeners, which are unreliable and can harm cache eligibility. MDN’s pagehide event reference recommends visibilitychange for session-ending signals and describes pagehide as the compatible fallback for navigation-sensitive cleanup.
Discarding cannot be handled at the moment it happens
A discarded tab has no opportunity to run a final callback; the browser is reclaiming its resources precisely because the page will no longer execute. Applications must prepare earlier, especially while transitioning from hidden toward frozen. On a later reload, document.wasDiscarded can indicate that the previous instance was discarded.
Recovery should be ordinary, not exceptional. Restore saved drafts, reestablish connections, refetch time-sensitive data, and explain if unsaved transient work could not be recovered. Service workers may help with offline resources, but they do not make an in-memory page immortal. Our service workers guide explains that boundary.
Lifecycle-aware pages waste less
Hidden pages should pause visual rendering, reduce timers, stop unnecessary polling, and avoid transient notifications that the user cannot see. Passive pages remain visible, so they should stay current while deprioritizing background computation. Active pages deserve the quickest response to input. Matching work to the state improves battery life and reduces contention across the browser.
The Page Visibility API guide covers the core visible-versus-hidden signal. Page Lifecycle extends that thinking into freezing, restoration, navigation caching, and discard recovery.
Design for interruption from the beginning
Lifecycle resilience comes from small habits: persist meaningful state before termination, make initialization safe to repeat, treat cached restoration as a real path, close resources before freezing, and refresh stale data after resuming. Test Back and Forward navigation, background the browser on mobile, and simulate long pauses rather than validating only a fresh load.
A page that behaves well under interruption feels calmer and more trustworthy. It does not demand permanent access to the machine’s resources; it cooperates with the browser, preserves what matters, and returns ready when the user comes back.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.