Archive for March, 2009:
gZip your JavaScript
Most browsers these days (with the exception of Safari, I think?) will accept gzip encoded content. This means you can drastically reduce the size of all those bloated javascript libraries you might be using on your web site.
So how do you serve gzipped js files?
There a few methods out there. I chose the one below since it was fast, easy and I’m hella freakin’ lazy.
The first step is to gzip all of the javascript files that you might be serving up. The fastest way I found was to just telnet into the server, and execute the following bash command:
gzip -cr <javascript directory>
Of course you’ll need to replace <javascript directory> with the correct directory that your javascript files are located in. The -c option tells gzip to keep the originals. This is important so that you can still serve non gzipped versions to browsers that don’t handle gzip! The -r option tells it to recurse through the directory. Now you should have a directory full of javascript files and their gzipped counterparts.
init.js
init.js.gz
jquery-ui.js
jquery-ui.js.gz
jquery.easing.js
jquery.easing.js.gz
jquery.history.js
jquery.history.js.gz
jquery.js
jquery.js.gz
swfobject.js
swfobject.js.gz
Yay. How exiciting, no?
The next step is to modify .htaccess to do some URL rewriting.
AddEncoding gzip .gz
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]
Essentially your telling the web server to server up gzip files, if the browser accepts them and the user is not on Safari and if there is a compressed version of the file available.
That’s really about it.
Here’s the difference in file sizes:
| File | Size | Size (gZip) |
|---|---|---|
| init.js | 7628 | 1992 |
| jquery-ui.js | 127787 | 50756 |
| jquery.easing.js | 8097 | 2003 |
| jquery.history.js | 5079 | 1771 |
| jquery.js | 31033 | 15666 |
| swfobject.js | 6722 | 2233 |
Pretty significant size difference!
IE and responseXML issues
After working on a small AJAX library, I decided to test it in IE. Everything worked great, except when requesting XML. The responseXML property of the XHR was null. I’ve had this issue in the past where the server isn’t returning the appropriate Content-Type (text/xml). But that wasn’t the issue this time. I checked my resin config and everything was correct.
So, I uploaded to a remote server and tried again. Blammo. Chit just worked the way it was supposed to. This left me scratching my head however.
I installed Charles (www.charlesproxy.com), which is a great debugging HTTP proxy/monitor, to see what was going on. Everything worked as it should in FireFox, but still no dice in IE.
Then I noticed that traffic wasn’t being captured for Localhost when using IE. After a bit of stumbling around the net I found that if you add a period right after localhost, Charles will capture the traffic.
http://localhost:8080/ajaxTest.html
becomes:
http://localhost.:8080/ajaxTest.html
When I reloaded the page, I got a very nice surprise. Not only did Charles capture the traffic, but the XHR returned with a proper responseXML property!
I’m no network engineer, so I’m not even going to try and guess as to WTF. But, I’m happy it works as expected and thought I’d post about it in case someone else ever runs into this issue.
