In many cases it will only be a few packets anyway so won't actually
make that much difference!
The point is that it is better to stop the request in the first place by
setting the appropriate expires/cache control header... than use the
etag mechanism...
James
On 09/06/2015 14:56, Frederik Nosi wrote:
Hi James,
On 06/09/2015 02:36 PM, James Smith wrote:
Yes - it is the request over head - the client will still make the
request at which point the server has got to decide has it changed
before even - which for most static requests is the heaviest
(slowest) part before returning the not-changed response - and then
serving the content!
But at this point the server in case of a positive match will send
just a 304 reply with no content, thus saving bandwith and time (due
to eventual roundtrips) no?
You are better to:
(a) set near future or mid future headers [ expires in a month or in
a year]
Sure, the best request is the one that does not even come :-)
(b) alter filenames if you significantly change the file contents [
we use MD5 of content for js/css ]
This only if you're in the posisition to decide the site layout though.
Note this is "hyper-tuning" of Apache... some people may want to
enable it - it was originally set up when most users were on
28K/33.6K modems (or slower) and the transfer of data was the slow
part of the equation!
James
[...]
Thanks,
Frederik
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
