If we do not support IE6, does it make sense to gzip Javascript files for IE?

Question

I am using the Django GZip middleware (django.middleware.gzip.GZipMiddleware) to compress content if the browser allows compression.

If the browser is Internet Explorer (MSIE) and the content is a Javascript file, then the middleware does not gzip the content. My understanding is that the middleware avoids compressing in this case because IE6 (without patches) has issues with gzipped responses.

For our site, we do not support IE6, but we do support IE7 and IE8. Considering that we do not support IE6, would it be best practice for us to gzip all javascript files even if the browser is IE?

If so, what is the best approach for getting these files gzipped? We would like to continue to use a Django middleware module for gzip. Should we make a copy of the gzip middleware module and edit the few lines that deal with IE and Javascript (this feels like we would be violating DRY)? Using Apache for gzip is also an option.

Answer 1

It most certainly would be advisable to use compression wherever possible yes. Bear in mind though that some browsers are fussy when it comes to compression. If you have the ability to use a .htaccess file on your hosting space, a simple conditional check for browsers can do wonders, like so:

    </IfModule>

    <IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/html
        AddOutputFilterByType DEFLATE text/plain
        AddOutputFilterByType DEFLATE text/xml
        AddOutputFilterByType DEFLATE text/css
        AddOutputFilterByType DEFLATE text/javascript
        AddOutputFilterByType DEFLATE application/xhtml+xml
        AddOutputFilterByType DEFLATE application/javascript
        AddOutputFilterByType DEFLATE application/x-javascript
        AddOutputFilterByType DEFLATE application/json
        AddOutputFilterByType DEFLATE application/xml
        AddOutputFilterByType DEFLATE application/rss+xml
        AddOutputFilterByType DEFLATE application/rdf+xml
        AddOutputFilterByType DEFLATE application/atom+xml

        #Netscape 4.x has issues, sort them out...

        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        Browser

Match \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

First we check to see if the module is enabled, set our compression options, and lastly sort out all those bad browsers!

Answer 2

Versions of IE6 that are affected by problems with gzip on JS/CSS are no longer in common circulation (and were a minority case even at the time). And Netscape 4 is long, long gone.

For this reason I would strongly recommend removing all extant User-Agent-sniffing gzip hacks. Send compressed HTML/JS/CSS to all browsers that request it (with Accept-Encoding), as per standard HTTP/1.1.

if "msie" in request.META.get('HTTP_USER_AGENT', '').lower():

Oh dear. That's a really poor test even by UA-sniffing's dismal standards. No checking that it's actually MSIE in the right place in the string (as opposed to anywhere in all the trailing bits; easy to get false positives), and it doesn't check for SV1 which was traditional for the gzip test (as IE6SP2+ versions cannot be affected by the bug), so it breaks compression for all IE which is just unnecessary.

It also doesn't set Vary: User-Agent, so proxies will cache the wrong version. And it sets Vary: Accept-Encoding for IE when not using Content-Encoding, so it'll break cacheing in IE.

Should we make a copy of the gzip middleware module and edit the few lines that deal with IE and Javascript (this feels like we would be violating DRY)?

You could, and maybe submit the patch to Django. Because their current approach is IMO simply broken.

Using Apache for gzip is also an option.

Yes, if you've got Apache upstream definitely use that (eg. with mod_deflate). It's most efficient if you can use it to serve static files like scripts too. (Try to keep your JS in static scripts rather than generating/templating on-the-fly.)

Again, don't use the browser-sniffing rules mentioned on the mod_deflate page. They're fragile and ugly, and are trying to code around a Netscape problem that has affected no-one in the last decade.

Answer 3

Since "Django itself doesn’t serve static (media) files", it would seem that the best practice would be to have Apache (or Nginx, Cherokee, or lighttpd) handle the gzip compression of javascript files.