Bearfruit

I am in an odd situation, maybe you can relate. I cannot easily serve dynamic content based on individual user/browser preferences. For me, its because my site is behind a somewhat dumb but effective caching proxy. However, this could as easily be applicable if you were hosting content on a site that only allowed static HTML content.

However, I’d still like to benefit from the phenomenal performance boost of using gzip’d Javascript and CSS (often a 70% reduction in file size). So is there a way to detect if the browser handles gzip’d media files using only client-side code? YES, here’s how:

First of all, neither Safari 3 nor Konqueror 3 or 4 seem to support it. Yes, even with the proper HTTP Content-Encoding header they just try and download the gzip’d javascript file. If you know a way around this, please enlighten me. Therefore we can make life simple and not even try if the browser’s user agent string has KHTML in it.

Then what we do is try to download a small gzipped javascript file that contains only one line of code that sets a global variable. In a separate script tag we check to see if the global variable is set. If so, we use scripts and css files that are gzipped, otherwise we use files that have been packed in some way.

I’m not a big fan of making extra http requests so I’ve also implemented a simple cookie method of remembering the results of the test.

You can see the code in action. This is an extremely simplified example.

Is there a better way? I’d love to hear how this can be improved.

Is this worth it? I think so. For example:

• Mootools complete library: minified = 45k, packed = 31k, minified and gzipped = 14k.
• Jquery complete library: minified = 52k, packed = 29k, minified and gzipped = 16k.
• Blueprint css framework: (mine is customized with some plugins) minified = 7.3k, minified and gzipped = 2.3k.

There’s one more benefit besides the download size. If you’ve ever tried debugging your site that used packed or minified js or css files, it can be quite a chore. With gzip compression you can now serve relatively easy to read and troubleshoot js files. The mootools package with only the docs stripped weighs in at 61k. However gzipped it’s 16k, only 2k larger than the minified+gzipped version. Now, when you click an error or single step through your code in firebug you can more easily see whats going on.

Here’s how you use it. Create gzipped versions of your files whose filename differs only in that it has a .gz at the end. So, MyWonderfulLibrary.js would be complimented by MyWonderfulLibrary.js.gz. Note that it is not essential to have the same content for both files, though I’d expect you would want the same in most cases. The gzip_test.js file looks for a gzip_test.js.gz file which you can download from the test site, along with the rest of the code.

The code to use looks like this:

  <script type="text/javascript" src="gzip_test.js"></script>
  <script type="text/javascript">
  <!--
  // ensure the noscript gets updated when you changes this
  styles = [ ['style.css','screen'], ['print.css','print'] ];
  scripts = [ 'mootools.v1.11.js', 'transcorners2.js'];
     // this can be a path that will get prefixed to each css or js file
     prefix = ''; 
 
     createCookie('gzip_enabled', gz_en, 30);
     writeTags(styles, 'css', prefix, gz_en);
     writeTags(scripts, 'javascript', prefix, gz_en);
     // -->
     </script>
     <noscript>
         <!-- keep necessary equiv css files here -->
     </noscript>

I’d really like to hear ideas on better ways to do this

Leave me a comment to tell me how off-base I am and what I can do to improve this. Please.