YSlow grade A (96) but not with doubts

06 August 2007   0 comments   Web development

Powered by Fusion×

YSlow grade A (96) but not with doubts 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

Thank you for posting a comment

Your email will never ever be published


Related posts

Previous:
Interesting lesson learnt on shortcut taking in usability 02 August 2007
Next:
html2plaintext Python script to convert HTML emails to plain text 10 August 2007
Related:
Crash-stats just became a whole lot faster 25 August 2015
How to test if gzip is working on your site or app 20 August 2015
Gzip rules the world of optimization, often 09 August 2014
HTML whitespace "compression" - don't bother! 11 March 2013
All your images are belong to data uris 06 January 2013
Secs sell! How frickin' fast this site is! (client side) 30 March 2012
Comparing Google Closure with UglifyJS 10 July 2011
DoneCal gets a grade A (92) 27 November 2010
Javascript tip: nifty use of the console.log function in Firebug 07 November 2010
Why I gave up on JQuery UI's autocomplete 20 October 2010