Most everyone is familiar with the .zip extension, the ubiquitous format that archives and compresses files for storage and transmission. Relatively few are aware of the server-side equivalents of gzip and deflate, collectively referred to as “HTTP compression”. Using gzip on your site can reduce web page sizes by up to 70%, creating faster page load times while reducing bandwidth costs, with almost no downside.

Unlike .zip, which is often a manual process, compression and decompression of gzip files is negotiated automatically between the server and browser during the HTTP request process. gzip is one more step in compression: before initiating gzip, you should first have optimized and post-optimized your images and code.

The good news is that every browser in common use accepts compressed HTTP content, and many servers automatically do so. You can test if your site supports gzip by using a free service such as checkgzipcompression or gzipWTF.

If that test returns negative, you’ll have to turn on gzip for your server. The easiest way to do so is by creating an .htaccess file with the correct commands, uploading the result to the root folder of your site.

Understanding .htaccess

.htaccess files control the behavior of the server at a local level: denying a browser access to certain files or folders, modifying and redirecting URLs, or (in this case) changing files. A .htaccess file can be created in a common text editor, such as Notepad, or in a fully-fledged IDE. Before you do so, you should be aware of two things:

• It is very likely that your operating system, be it Windows, Mac OS X or Linux, will automatically hide any .htaccess file you create, as any filename that starts with a period is regarded as a protected system file. This extends to IDEs such as Coda, which may not show the file in folder listings by default. You may have to force a Show hidden files option in order to see the file you created.
• .htaccess files are powerful juju: adding a typo may disable access to your entire site, or stop your HTML pages from being delivered correctly to the browser. Work slowly, carefully, and methodically. Ideally, test your .htaccess file on a local development server before deploying it to production.

HTTP Compression via .htaccess

First, check that you don’t already have a .htaccess file in your root folder (it’s unlikely, but you don’t want to overwrite a file if it’s already there). Use the existing file, or create a new one, which must have .htaccess exactly as the file name.

I’m going to assume you run Apache as a web server, which is the most likely option. In that case, write the following near the top of the .htaccess document:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|svg|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_include mime ^image/svg+xml.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

Then upload the file to the root folder of your site. Usually, that is the same location as your index page.

Then test the site for gzip support by using one of the services above. If you don’t see any changes, it’s likely that your hosting service server doesn’t support gzip. It’s possible that it will support mod deflate, a related compression option. In that case, replace the code above with:

<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript image/svg image/svg+xml
</ifmodule>

… and try the services again.

What Do These Commands Do?

Broadly, both sets of commands seek to achieve the same thing: compressing text, HTML, CSS and JavaScript files on the server and sending these compressed versions to browsers that request them. If the browser doesn’t accept gzip or deflate encoded content (very rare, but still a possibility), the original content is sent instead. Update the original file on the server, and a new compressed version is automatically created.

Note that bitmap images and other media are not compressed: adding server-side compression to files that are already well-optimized will often increase the file size, rather than reducing it. SVG files are a notable exception: as they are text-based, they can be further compressed after optimization.

If .htaccess fails

If both .htaccess options fail, it’s likely that your site is hosted on a server that doesn’t support gzip or deflate options, or disallows .htaccess files from modifying site content. In that case, I would contact the company and ask them to turn gzip on.

If the answer is still no, there is one other option. It’s not as effective as mod_gzip or mod_deflate, but it’s better than nothing. So long as you’re using PHP, simply add this line to the very start of every page:

<?php ob_start("ob_gzhandler"); ?>

“At the very start” means just that: the function can fail if there’s a single space before the PHP, although most servers are more forgiving.

Conclusion

Using HTTP compression is a no-lose proposition: the only downside is a slightly increased load on server processing. This cost is more than offset by the savings and advantages to your site.

If you run your own server (either a virtual server or a dedicated machine) you can gain a slightly greater advantage by placing the gzip commands in your apache httpd.conf file instead. As its name suggests, the .htaccess file is consulted with every HTTP request to your site; commands written in httpd.conf are read just once on server startup, and offer better performance. I’ll detail httpd.conf options in a future article.

Photograph from MeditationMusic.net, used with permission.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.