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.
|
