Monday, September 28th, 2009

Going into details with the WebKit Page Cache

Category: Browsers, WebKit

Brady Eidson has a great one two punch on the WebKit page cache. First, Brady delves into the basics of the page cache:

The Page Cache makes it so when you leave a page we “pause” it and when you come back we press “play.”

When a user clicks a link to navigate to a new page the previous page is often thrown out completely. The DOM is destroyed, Javascript objects are garbage collected, plug-ins are torn down, decoded image data is thrown out, and all sorts of other cleanup occurs.

When this happens and the user later clicks the back button it can be painful for them. WebKit may have to re-download the resources over the network, re-parse the main HTML file, re-run the scripts that dynamically setup the page, re-decode image data, re-layout the page, re-scroll to the right position, and re-paint the screen. All of this work requires time, CPU usage, and battery power.

Ideally the previous page can instead be placed in the Page Cache. The entire live page is kept in memory even though it is not on screen. This means that all the different bits and pieces that represent what you see on the screen and how you interact with it are suspended instead of destroyed. They can then be revived later in case you click the back button.

Then in part two we get deeper, and delve into the page show/hide events:

  1. <html>
  2.     <head>
  3.     <script>
  5.     function pageShown(evt)
  6.     {
  7.         if (evt.persisted)
  8.             alert("pageshow event handler called.  The page was just restored from the Page Cache.");
  9.         else
  10.             alert("pageshow event handler called for the initial load.  This is the same as the load event.");
  11.     }
  13.     function pageHidden(evt)
  14.     {
  15.         if (evt.persisted)
  16.             alert("pagehide event handler called.  The page was suspended and placed into the Page Cache.");
  17.         else
  18.             alert("pagehide event handler called for page destruction.  This is the same as the unload event.");
  19.     }
  21.     window.addEventListener("pageshow", pageShown, false);
  22.     window.addEventListener("pagehide", pageHidden, false);
  24.     </script>
  25.     <body>
  26.     <a href="">Click for WebKit</a>
  27.     </body>
  28.     </head></html>

Oh, and beware of plugins ;)

Secondly, a page might not be considered for the Page Cache because it’s difficult to figure out how to “pause” it. This happens with more complex pages that do interesting things.

For example, plug-ins contain native code that can do just about anything it wants so WebKit can’t “hit the pause button” on them. Another example is pages with multiple frames which WebKit has historically not cached.

Distressingly, navigating around these more advanced pages would benefit the most from the Page Cache.

Posted by Dion Almaer at 6:33 am

3 rating from 15 votes


Comments feed TrackBack URI

Totally off topic, but I just noticed how awful the Ajaxian background looks with smooth scrolling on an LCD.

Comment by Darkimmortal — September 28, 2009

Isn’t this what Opera has been doing for ages? (like, at least around since they got the rewind/fast forward buttons, Opera 8 was it?).

Comment by gonchuki — September 29, 2009

Leave a comment

You must be logged in to post a comment.