NinoGames Browser Navigation Guide: Why Back/Forward Cache Can Restore Old State Without a Reload

<back/forward cache, or bfcache, is a browser feature that enables a page to be saved in memory so that when the user navigates back or forward, the entire page can be restored instantly. This performance improvement is especially beneficial on mobile devices where loading a new page involves time-consuming tasks such as DNS resolution, establishing a secure connection (TLS), rendering HTML, executing JavaScript, fetching images, and initializing the application.

However, this convenience comes with a potential drawback: when a restored page appears, it may display information that is outdated because the server, account session, timers, or live data may have changed while the page was inactive. The critical concern for developers dealing with web-based services, like NinoGames, is whether their application can differentiate between a restored snapshot and a genuinely updated view.

This article aims to provide developers with a better understanding of bfcache mechanisms, page lifecycle events, and strategies to manage state restoration effectively. It is important to note that the article does not specifically discuss NinoGames' implementation of bfcache or Android WebView configurations; rather, it serves as a general guideline for web application development across various platforms.

To grasp the concept fully, it is essential to distinguish between HTTP caching and bfcache. While both can speed up repeat navigation, they operate differently. HTTP caching stores response data like HTML, scripts, stylesheets, images, and API responses according to predefined caching rules. On the other hand, bfcache creates a full in-memory snapshot of the page, capturing the Document Object Model (DOM) and JavaScript runtime environment.

This snapshot allows the browser to resume the page's state exactly as it was when the user left, without needing to resend requests or reinitialize JavaScript logic. This distinction is crucial for developers because it means that while HTTP caching deals with reusable response data, bfcache deals with a complete page state. Understanding this difference is key when debugging and ensuring that restored pages behave as intended.

For developers, the `pageshow` event plays a pivotal role in handling bfcache restoration. This event is triggered on both normal page loads and history restorations from bfcache. By listening to the `pageshow` event, developers can use the `PageTransitionEvent` object to check if the document has been restored from a cache, as indicated by the `persisted` property.

This property is `true` when the page is being restored, allowing developers to execute specific logic designed to handle restored states. Here's a simple implementation pattern that developers can use:

```javascript

window.addEventListener('pageshow', function(event) {

if (event.persisted) {

revalidateVolatileState();

}

});

```

The key takeaway here is not the function name or the event detail but the recognition of the `persisted` state. When a page is restored from bfcache, the `persisted` event allows developers to identify that the page is being reloaded from the cache rather than a fresh network request. The next step in this process is to determine how to handle the restored state.

The goal is not to treat every restored page as needing a full reload but to selectively revalidate only the parts of the UI that are volatile or time-sensitive. This selective revalidation approach can range from simple tasks such as refreshing timestamps or session states to more complex actions like checking tokens, re-fetching data, or resetting subscriptions.

By carefully distinguishing between static and dynamic content, developers can maintain a fast navigation experience while ensuring that the user sees the most current information. For instance, scroll position, expanded panels, form values, and display content can be safely restored without any intervention. In contrast, server-generated data such as balances, queue states, availability indicators, or countdown timers may need to be refreshed using lightweight status requests, version checks, or authentication refreshes.

This selective approach also addresses the sensitive nature of authentication and authorization. A restored page can still be considered unauthorized if the user has taken actions like signing out in another browser tab or if their account information has changed. Special handling is required to ensure that restored pages reflect the current user state.

In summary, bfcache is a powerful tool in modern web browsers that significantly enhances user experience by reducing load times. However, it introduces complexities in state management that developers must address to maintain the accuracy and freshness of their web applications. By leveraging events like `pageshow` and `PageTransitionEvent.persisted`, implementing selective revalidation strategies, and handling authentication and authorization appropriately, developers can create web applications that take full advantage of bfcache while ensuring that their users always see the most up-to-date information.