Optimize Page Load Time with Gzip Compression
HTML, CSS and Javascript compression is a simple and effective way to save bandwidth and optimize page load time on your site. It’s often overlooked and yet simple to implement, just enable gzip compression for the right document types and enhance your site’s user experience.
In Apache, we achieve this by enabling content encoding. When a user requests a file like http://www.msn.com/index.html, the browser communicates to a web server, and the conversation goes a something like this:
1. Browser: GET me /index.html
2. Server: Found indes.html, it’s 187KB! Response code is 200 (200 OK) , requested file is coming
3. Browser: 187KB, loading
The actual headers and protocols sent between the two are much more formal (monitor them with HTTPFox, Live HTTP Headers or others if you like.
Now, everything worked just fine in our little scenario, the browser got it’s requested file (index.html) of 187KB in size and probably also loaded include files such as javascript, css and a bunch of images. Especially on lower speed Internet connections, it took a few seconds for the page to load all files.
That’s where gzip compression comes in. Html, javascript and css are plain text content and therefore ideal candidates for gzip compression. On the contrary, images and videos usually underwent some compression algorithm when saved as jpg, png, avi or flv. Compressing those files would provide very little to no improvement in file size and would only add processing overhead to the web server. We want to ensure that we exclude those type of files from gzip compression.
1. Browser: GET me /index.html, compressed if available
2. Server: Found index.html, it’s 35KB, compressed! Response code is 200 (200 OK) , requested file is coming
3. Browser: got index.html, extracting and loading
How do the browser and server know whether to send a file compressed or not? The agreement has two parts:
1. The browser sends a header during the request, telling the server it accepts compressed content (Accept-Encoding: gzip, deflate)
2. The server sends a response if the content is actually compressed: Content-Encoding: gzip
If the server doesn’t reply with the content-encoding response header, it means the file is not compressed. The “Accept-Encoding” header is just a best effort request, meaning the server can respond either way.
Setting up the web server to enable page compression
To enable html, css and javascript compression in Apache, we add the output filter “Deflate” to the apache config, or .htaccess file. The latter is only recommended if you’re on a shared hosting plan and don’t have access to the config files. Here we declare several different formats, also called MIME types, to be delivered compressed if requested:
<Directory "/your-server-root"> AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript </Directory>
We encourage you to read more about mod_deflate. There is also a another option next to “mod_deflate”, the external “mod_gzip” module and can be found here. Note that:
– mod_deflate is easier to set up and is standard.
– mod_gzip seems more powerful and you can pre-compress content.
In either case, Apache checks for the “Accept-encoding” header and returns either the compressed or regular version of the file. Some older browsers however may have issues and there are special directives we can add to handle them like such:
BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSIE !no-gzip !gzip-only-text/html
Once we’ve configured our server, let’s verify that we’re actually serving up compressed content.
– Online: Use the online gzip test to check whether your page is compressed.
– In your browser: Use Firebug and inspect the header for “Content-Encoding”
– View the headers: Use HTTPFox or Live HTTP Headers to examine the response headers.
Some issues to watch out for when enabling compression:
– Older browsers still can have trouble with compressed content (they say they can accept it, but really they can’t). If your site absolutely must work with Netscape 1.0 on Windows 95, you may not want to use HTTP Compression. Apache mod_deflate has some rules to avoid compression for older browsers.
– Already-compressed content: Most images, music and videos are already compressed. Don’t waste time compressing them again. In fact, you probably only need to compress the “big 3″ (HTML, CSS and Javascript).
– CPU-load: Compressing content on-the-fly uses CPU time and saves bandwidth. Usually this is a great tradeoff given the speed of compression. There are ways to pre-compress static content and send over the compressed versions. This requires more configuration; even if it’s not possible, compressing output may still be a net win. Using CPU cycles for a faster user experience is well worth it, given the short attention spans on the web.
