Bug 5344 - Safari shouldn't re-download certain subresources on back
Summary: Safari shouldn't re-download certain subresources on back
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://slashdot.org
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-11 20:28 PDT by Samuel Allen
Modified: 2010-01-22 19:29 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Allen 2005-10-11 20:28:43 PDT
With Firefox 1.5, the rules that determine whether or not to download content from pages already 
stored in the cache has changed. When going back, certain sites like Slashdot.org do not load any 
subresources from the network. Instead, it is all stored locally. This is part of Firefox's solution to speed 
up back and forward.

Safari has a back and forward cache but even greater perceived gains could be realized if Safari were to 
emulate this way of determining whether or not to download subresources.

To test this out, load http://slashdot.org and click on a comments link. Then, go back. On a slow 
connection the page will only render half way, then wait for the ad to load and the rest will be rendered. 
Now do the same with Firefox 1.5. The page is rendered instantly without going to the network.

A change to not load from the network any resources from pages in the back-forward list would speed 
up back and forward tremendously. Safari has a faster engine so this might compensate for not having 
as robust of a back forward cache as Firefox has.

This is related to the bug I filed on the back-forward cache not being as robust as Firefox's, but it could 
be fixed independently. All that needs to happen here is for Safari to know to use a cached ad (for 
example) instead of downloading a new ad.
Comment 1 Joost de Valk (AlthA) 2006-02-13 15:57:16 PST
Reassigning to webkit-unassigned, to make sure more people see this.
Comment 2 Alexey Proskuryakov 2006-06-26 05:14:40 PDT
Currently, I see that Firefox 1.5.0.4 does cause quite a bit of network activity when going back from a comments page. Also, WebKit is supposed to use NSURLConnection cached data on Back/Forward, even if if it's expired, so I'm not sure how Firefox could be more aggressive.

Perhaps, it's just the ad code on Slashdot that has changed to prevent caching? Do you have some other example where Firefox performs no network access on back/forward, but Safari does hit the network?
Comment 3 Ilgaz Öcal 2007-04-21 07:24:27 PDT
I am really having hard time to understand why this feature request to change the browsers internal working mechanism shows up it unconfirmed P2 bugs list.

Caching everything could work great but it has own side effects too. A browser known to cache everything and check in 5 hours by default (unless stated different by page/headers) is Opera and it has own unique problems because of that.

Speaking about Slashdot, if Slashdot tells browser not to cache (since it is highly dynamic site) and browser cares about it, it is normal behaviour while other browsers caching the "do not cache" pages is actually a bug waiting to happen IMHO.

Adding feature requests as P2 bugs to the major/final version of browser won't help them to get implemented, it will rather make ordinary end users care less about the unconfirmed,real bugs. I think the page caching is related to browsers design and the philosophy of it, all back to KHTML.

As another side note, thanks to Fink , I actually have Konqueror 3.5.6 (current,latest final version) and it indeed re-loads some of resources while clicking back/forward. As a slashdot subscriber, I can happily test if it is related to ads or not but I'd assume as a person using /. for long time that it is indeed related to the highly dynamic content of site and it is by slashcode design.
Comment 4 Mark Rowe (bdash) 2007-04-21 08:23:35 PDT
This does not seem to be related to HTTP caching based on the description, but rather to the page cache not handling pages with frames or iframes correctly.  The behaviour of Opera's caching in different circumstances is not particularly relevant, and the behaviour of KHTML could easily be due to it sharing the same issue.

Ilgaz, I'm not sure why you're lecturing the originator of this bug on Bugzilla etiquette.  From what I've seen this is your first appearance on WebKit's Bugzilla, and I don't think it is appropriate to be making such statements until you are familiar with the policies and etiquette used in the WebKit community.  Based on the description of the bug, a P2 bug of "Normal" severity looks fine to me.  It could be argued that this is an enhancement, but as we don't pay much attention to that field it makes little difference anyway.
Comment 5 Alexey Proskuryakov 2010-01-22 19:29:33 PST
Even with the fix for bug 33993 in place, WebKit makes several HTTP requests when going back to main page of Slashdot. Firefox 3.5 doesn't make any.