The back/forward cache in Safari is nice when it works, but it doesn't work for many popular web sites. The new cache in Firefox (Deer Park Alpha 2) works for many of these sites. So, browsing these sites in Firefox is much faster than browsing them in WebKit ToT. As I understand it the cache is only activated when a site doesn't have any frames. Unfortunately some of the slowest-to-load sites have frames, so the utility of the current cache is limited. Also, Deer Park seems not to re-fetch ads and such from the network when the fastback feature is activated, whereas WebKit goes out to the network, which makes Firefox faster still.
Yeah, unfortunately our b/f cache does not work with iframes (or on pages with login fields).
This problem is making Safari look bad compared to Firefox 1.5. See this MacWorld article http://www.macworld.com/news/2005/12/02/ff15look/index.php
Is this being worked on? An improvement in this area would improve the whole feel of the Safari browsing experience.
Agreed. Unfortunately making the b/f cache work with frames is hard. It would be nice to at least fix the login field problem (which IMO is even worse than the iframe problem).
I am aggressively pursuing this at the moment. Since this bug report is very general and lacks specifics, I have split off what we consider to be 3 major tasks into their own bugs: http://bugs.webkit.org/show_bug.cgi?id=13629 http://bugs.webkit.org/show_bug.cgi?id=13630 http://bugs.webkit.org/show_bug.cgi?id=13631
Not sure under which of the depending bugs this should go, but a site that always seems to reload pages from scratch, and is very slow in doing so, is http://soccernet.espn.go.com/. Navigating around that site is slow and painful, even just flipping back and forth between two different pages. NB Firefox is not that great on the site either. Webkit is slightly better than released Safari, but still seems to reload from network when going back to a previously visited page. Also note, which may be related to the cache, if you go to their scores page and have it set to reload every 45 seconds (e.g. http://soccernet-akamai.espn.go.com/scoreboard?league=eng.1&date=20070428&refresh=45&cc=5901) and then scroll down on that page, when it reloads the scrolling position is not remembered. This can be annoying on game day.
espn is notoriously slow in just about all browsers, unfortunately. However you're talking about general caching of resources, not the back/forward cache. As for the scroll position being lost when reloading the page, see http://bugs.webkit.org/show_bug.cgi?id=13266
My apologies, 13266 wasn't the one I was looking for. The one I meant was http://bugs.webkit.org/show_bug.cgi?id=13422
For the soccernet site, the loss of scrolling position upon reload is not a regression - the same behavior is also exhibited in release Safari, as well as TOT Webkit, so I suspect that there may be different underlying causes between the soccernet problem and the one in http://bugs.webkit.org/show_bug.cgi?id=13422
Wow, I just downloaded a new nightly build for Windows and the back/forward cache seems to be in it. My observation is that the cache seems to work much better than it did 2 years ago, and pages with form controls are cached more often. Many sites on the Internet unfortunately do not work with the back/forward caches of Firefox, Opera, and Safari however. I don't have a list of all the specifics but it seems to me that this feature is solid enough for this bug to be closed, as WebKit has feature parity with Firefox and Opera (as far as I can tell). I know that sites such as http://ubuntuforums.org/ didn't used to work with the cache, and now they do. The point of this bug was not to perform a detailed analysis of all sites, but just to document the general problem. Therefore, I think it should be marked FIXED.