If you're a web developer and care about having snappy web sites you'll know about YSlow for Firebug. I managed to get a grade A (96) but I'm suspecting that there's a bug in the YSlow analysis.
Setting an Expires
header is inferior to using Cache-Control
which my site was already using fine with headers like:
Cache-Control: public,max-age=3600
according to the latest documentation but YSlow kept going on about setting Expires
headers. I prefer Cache-Control
since you don't have to do any date formatting which eats a few excess CPU cycles. If anybody knows why it's a good idea to use both Cache-Control
and Expires
let me know.
A more worrying possible bug in YSlow is that it's date comparison on the Expires
header is wrong. I use the RFC1123 format for the Expires
header which uses GMT which means today that the output looks like it's one hour behind since we're (here) in BST (British summer time). Here are the different outputs:
`date` on command line Fri Aug 6 17:26:36 BST 2007
looking at my wrist watch 17:26
RFC 1123 Fri, 06 Aug 2007 16:26:36 GMT
(RFC 822 Fri, 06 Aug 2007 17:26:36 +0100)
If I add 5 min to the RFC 1123 YSlow claims the date is not in the future which is incorrect. To get my A grade I set the Expires
future parameter to be 1 hour and 5 min ahead to not confuse YSlow's date comparison. But if YSlow gets it wrong perhaps HTTP accelerators (eg. Squid) and web browsers might get it wrong too.
This site isn't launched yet but one of the things I'm quite proud of is that I'm managed to whitespace-strip, merge and gzip the javascript files and the css files and all of this happens once per server reload meaning there's nothing dynamic in these files but when I make a change all I have to do is save the file and the system automatically recompiles a new merged, stripped and gzipped version absolutely seamlessly.
This is the first time I've put the Javascript at the bottom of the page which I'm not used to and slightly unsure what side effects that might have to the rendering. We'll see.
Comments