Bug 4123 - Back/forward cache does not cache enough pages
: Back/forward cache does not cache enough pages
Status: RESOLVED FIXED
: WebKit
History
: 420+
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To:
: http://www.tuaw.com/
:
: 13629 13630 13631 13634
:
  Show dependency treegraph
 
Reported: 2005-07-24 22:27 PST by
Modified: 2007-12-21 21:57 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-07-24 22:27:55 PST
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 From 2005-07-25 11:59:55 PST -------
Yeah, unfortunately our b/f cache does not work with iframes (or on pages with login fields).
------- Comment #2 From 2005-12-04 13:20:46 PST -------
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
------- Comment #3 From 2006-10-21 12:19:22 PST -------
Is this being worked on? An improvement in this area would improve the whole feel of the Safari browsing experience.
------- Comment #4 From 2006-10-21 14:51:25 PST -------
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 From 2007-05-08 19:52:40 PST -------
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
------- Comment #6 From 2007-05-09 00:10:48 PST -------
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 From 2007-05-10 10:44:22 PST -------
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 From 2007-05-10 10:48:30 PST -------
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 From 2007-05-12 16:14:48 PST -------
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 From 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.