Google turbo-charge the back button with the new Chrome "back / forward cache"



[ad_1]

Now, it's shiny chrome.
Enlarge / Now, it's shiny chrome.

Google is currently developing a new cache for Chrome (via CNET) that should make loading some pages extremely fast. The only take? They should be pages that you have already seen and revisit after pressing the browser's Back button.

Chrome is already caching the files that make up a page. Therefore, in most cases, revisiting a page should not require the browser to retrieve the images, Java scripts, and CSS scripts used to create the page. But currently, the browser must re-analyze the HTML code and rebuild the programmatic representation of the page, unzip the images, rerun all JavaScript, reapply all style sheets, and so on. This is simply the networking step that is ignored.

The new bfcache (for the "previous / next cache") changes: it allows the browser to capture the full state of a current page – including running scripts, rendered images, and even the current location. scroll – and reload this state later. With bfcache, rather than having to reload the page from scratch, the page will appear to be suspended when you click on a link to a new page and then resume when you click again.

Unlike file caches, which can speed up the loading of even new pages and extend over multiple browser sessions, bfcache will only accelerate the pages you have recently visited. As its name indicates, it is only used for navigation by pressing the Back and Next buttons to view your history. But Google says that such visits are an important part of traditional browsing sessions, with about 10% of pages on the desktop and 19% of mobile pages revisited.

Safari and Firefox have been using a similar type of caching for years. Safari calls this the page cache and has it since 2002, while the Firefox one is called BFCache. It exists in one form or another since Firefox 1.5 in 2005. Although Google's Blink engine has a common legacy with Apple's Safari WebKit engine, Google has chosen not to use the equivalent of WebKit in bfcache, claiming that it is incompatible with the multiprocess model used by Chrome.

Details, details

The devil with this kind of cache is in the details. Safari did not start using page caching for pages containing frames until 2009, nor caching sites served via HTTPS before 2012. Pages that use scripts to detect when they are remote can not not be cached. Firefox and Safari both include alternate installations so that scripts can indicate when their page is paused or resumed. The battery life of the new cache should be improved because resuming a suspended page will be much less intensive than rebuilding the page. But bfcache also threatens to increase Chrome's memory usage, which is already a big concern for the browser.

The work to allow this in Chrome is going to be considerable; A number of different parts of the browser must be coordinated to ensure that every part of a page, including scripts in the background, is properly frozen. As a result, the feature will be developed this year, but it is unlikely that we will find in stable versions of Chrome before 2020.

[ad_2]

Source link