On 19 Mar 2008, at 10:11, Per Jessen wrote:
Stut wrote:
On 19 Mar 2008, at 09:54, Per Jessen wrote:
BTW, why does the browser do this for objects it has already cached?
(assuming they're fresh/not expired)
Because by default most web servers don't add expiry headers, so it's
up to the browser.
My server does add expire headers - and I still see lots of 304s.
I've
checked that the expiry information is correct.
We see lots of them as well, but it's far less than before we added
far-future expiry headers.
Adding expiry headers for certain content types is very easy in most
web servers and depending on traffic patterns it can cause a very
healthy drop in traffic.
Combine that with a convention for new versions of the files as they
get changed and you can put the expiry date a long time into the
future. We use a year on all our images, css and js files and it's
lead to a drop of ~40% in traffic to the static servers.
Same here - I am just wondering about the need for the conditional GET
then. What makes the browser want to revalidate an object when it has
a valid (=unexpired) copy cached?
There could be a number of reasons ranging from browser configuration
to badly implemented caches. There's not a lot you can do about them
beyond making sure your expiry headers are working properly with the
major browsers.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
