WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
5344
Safari shouldn't re-download certain subresources on back
https://bugs.webkit.org/show_bug.cgi?id=5344
Summary
Safari shouldn't re-download certain subresources on back
Samuel Allen
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Joost de Valk (AlthA)
Comment 1
2006-02-13 15:57:16 PST
Reassigning to webkit-unassigned, to make sure more people see this.
Alexey Proskuryakov
Comment 2
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?
Ilgaz Öcal
Comment 3
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.
Mark Rowe (bdash)
Comment 4
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.
Alexey Proskuryakov
Comment 5
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug