Chrome users may now experience better page viewing when navigating through different pages. Google decided to update the Chrome browser’s bfcache feature for storing cached pages for faster loading during back/forward navigation.
Google Chrome Updates bfcache For Improved Performance
In a recent post, Google announced the introduction of some performance improvements for its Chrome browser. Specifically, the performance boost would arrive from the updates to the Chrome bfcache for quick page viewing.
Google describes bfcache on its web.dev website as a dedicated in-memory cache for browser optimization. It stores a complete snapshot of the website as the user navigates back or forward to another web page.
While such browsing may cause the already-visited web pages to take longer to load, with bfcache enabled, users can quickly return to their destination web page as the browser presents them with the cache. However, this bfcache doesn’t store web pages cache upon detecting the Cache-control: no-store HTTP header. This causes trouble in restoring pages during back/forward navigation.
To tackle this issue, Google proposed improvising the bfcache to continue storing the web caches even upon this header. As described,
This would allow pages to enter BFCache and be restored as long as there are no changes to cookies or network requests that receive response with “Cache-control: no-store” HTTP header.
With this implementation, where the HTTP requests remain consistent (given no changes to cookies or network requests), restoring pages during back/forward navigation will become easier and faster.
Though it sounds impressive for performance, this proposal has also triggered some privacy concerns, particularly regarding restoring web pages with sensitive content. Ideally, users should no longer retain access to sensitive content when navigating away, implemented with the Cache-control: no-store (CCNS) header, and denying which means retention of sensitive data.
However, Google addresses this problem by selectively restoring the non-sensitive data only. Regarding the “sensitive” data type, Google elaborated that local data isn’t considered a part of it. Rather, it counts fetched documents, data received via fetch and XMLHttpRequest, and data received from WebSocket, WebTransport, and WebRTC, as sensitive information that will remain a part of CCNS.
More details about this proposal are also available on GitHub.
Let us know your thoughts in the comments.