4123 2005-07-24 22:27:55 -0700 Back/forward cache does not cache enough pages 2007-12-21 21:57:18 -0800 1 1 1 Unclassified WebKit History 420+ Mac OS X 10.4 RESOLVED FIXED http://www.tuaw.com/ P2 Normal --- 13629 13630 13631 13634 1 allen.sam hyatt beidson gavin.sharp gsherloc oldest_to_newest 15153 0 allen.sam 2005-07-24 22:27:55 -0700 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. 15175 1 hyatt 2005-07-25 11:59:55 -0700 Yeah, unfortunately our b/f cache does not work with iframes (or on pages with login fields). 25515 2 allen.sam 2005-12-04 13:20:46 -0800 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 51525 3 akwb 2006-10-21 12:19:22 -0700 Is this being worked on? An improvement in this area would improve the whole feel of the Safari browsing experience. 51528 4 hyatt 2006-10-21 14:51:25 -0700 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). 10665 5 beidson 2007-05-08 19:52:40 -0700 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 10652 6 gsherloc 2007-05-09 00:10:48 -0700 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. 10612 7 beidson 2007-05-10 10:44:22 -0700 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 10613 8 beidson 2007-05-10 10:48:30 -0700 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 10175 9 gsherloc 2007-05-12 16:14:48 -0700 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 65051 10 allen.sam 2007-12-21 21:57:18 -0800 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.