Bug 4123 - Back/forward cache does not cache enough pages
Summary: Back/forward cache does not cache enough pages
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Dave Hyatt
URL: http://www.tuaw.com/
Depends on: 13629 13630 13631 13634
  Show dependency treegraph
Reported: 2005-07-24 22:27 PDT by Samuel Allen
Modified: 2007-12-21 21:57 PST (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Allen 2005-07-24 22:27:55 PDT
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.
Comment 1 Dave Hyatt 2005-07-25 11:59:55 PDT
Yeah, unfortunately our b/f cache does not work with iframes (or on pages with login fields).
Comment 2 Samuel Allen 2005-12-04 13:20:46 PST
This problem is making Safari look bad compared to Firefox 1.5. See this MacWorld article

Comment 3 Andrew 2006-10-21 12:19:22 PDT
Is this being worked on? An improvement in this area would improve the whole feel of the Safari browsing experience.
Comment 4 Dave Hyatt 2006-10-21 14:51:25 PDT
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).
Comment 5 Brady Eidson 2007-05-08 19:52:40 PDT
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:

Comment 6 Gavin Sherlock 2007-05-09 00:10:48 PDT
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.
Comment 7 Brady Eidson 2007-05-10 10:44:22 PDT
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
Comment 8 Brady Eidson 2007-05-10 10:48:30 PDT
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
Comment 9 Gavin Sherlock 2007-05-12 16:14:48 PDT
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
Comment 10 Samuel Allen 2007-12-21 21:57:18 PST
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.