More on compressing your website content for speed [PART I]

In one of my previous posts I explained how you could force GZip compression on your server, by specifically focusing on websites hosted within the HostMonster environment. The post has generated a lot of discussion, especially from those using the HostMonster as their web host. Recently, I did some additional research and experimentation that have revealed a few new things, which I will share with you in this article series. I should warn you that this is quite a long article. It is written to be instructive for those who may not possess advanced knowledge in this area because I too do not possess such advanced knowledge. I am by no means a professional at this, so please keep this in mind if you choose to implement the following techniques. This article is simply meant to share what I have discovered and hopefully get constructive feedback from those more knowledgeable in the area, so that we all can benefit.

A. Introduction to Part I

Before proceeding, please note that the content of this article was written quite some time ago when I had great success using the described method. It worked flawlessly on HostMonster and WPWebHost, two very reliable and affordable web hosting providers. Although I have resorted to using a slightly different (and easier) method, I still feel that this information may be useful to those who do not necessarily use WordPress.

B. Let’s get started

With the increasing amount of content and spectacular visual effects that many websites are utilizing these days, it should come as no surprise that there will come a point at which things will begin to slow down. Requiring that your visitors download large CSS and Javascript files, for example, can be an annoyance for those on slower internet connections. Furthermore, valuable website bandwidth is wasted just serving these files. One solution to reducing file size and thereby increasing website responsiveness for your visitors is to compress everything before serving. Here is how it can be accomplished using GZip compression.

External Articles for Further Reading

• Compressing Web Content with mod_gzip and mod_deflate
• How to Optimize Your Site with GZip Compression

C. Activate GZip compression for dynamic content

This was a bit confusing when I first discovered it, so I will try to explain as best I can. Compression can be passively performed by the server (as was the case being described in this post), or it can be actively performed (e.g. via PHP). I choose to focus on the former for now because others have suggested that it saves server resources. The latter triggers compression via PHP on every request, which you may not need, but I will write about it sometime in the future.

As you should have expected, in order to get GZip working properly, your server must support it and it must be activated. It is usually installed as an extension module to Apache, i.e. mod_gzip. You can perform a quick check to see if GZip is available for activation by checking phpinfo(); (see the PHP Manual). php.ini and .htaccess must also be configured. One important thing to note is that the configuration changes you make to php.ini activate server-side compression of dynamic content, not static content.

For those using HostMonster hosting: Several users have informed me that HostMonster does not support mod_gzip or mod_deflate for compression. At the time of writing this article I was successfully able to utilize GZip compression. Some time ago I heard that HostMonster added a “switch” to manually activate compression using mod_deflate instead via the cPanel, but this “switch” has suddenly disappeared. I have no explanation for why I am able to activate GZip while others can not; perhaps it has to do with the particular server your website is housed on. As a fallback for those having problems, I have included the settings needed to activate ZLIB compression instead, which I know for sure works in the HostMonster environment.

You can activate either GZip or ZLIB via php.ini, not both. Make the relevant changes to php.ini and save. This assumes that you have a master php.ini file that takes care of all of your PHP. If you maintain separate PHP environment settings for different sub-directories, you will need to make the following changes to the individual php.ini files.

Activate GZip compression on the server:
output_buffering = On
output_handler = ob_gzhandler
zlib.output_compression = Off

Activate ZLIB compression on the server:
output_buffering = Off
output_handler =
zlib.output_compression = On

[Note that there is no value set for output_handler using the ZLIB method.]

For completeness, add the following lines to your .htaccess file. If you are using WordPress, add the code after the default WordPress-inserted rules.

The lines above should trigger compression of text-based files only, not images. Forcing the compression of images may result in garbled output since many are saved in compressed formats to begin with. Try Smush.it for compressing images to save even more on bandwidth.

D. Activate GZip compression for static content

By now, you are probably asking yourself, “What?! Didn’t I just activate compression for static content using the above .htaccess code?” After all, are not external CSS and Javascript considered “static content”. That is what I thought as well, but for some reason none of my CSS or Javascript were being served compressed – at least not yet!

A server configured with GZip enabled will only present the compressed version of content to the client browser if the browser supports interpreting that compressed content. Most modern web browsers will send the proper request in their headers, while others have a bit of difficulty doing so. When there is no client-side support for interpreting compressed content, the uncompressed version is served instead. In a sense, this provides a fallback for a few website visitors using old versions of web browsers without this feature.

Some web browsers need to be “told” that the compressed content that they are receiving is of a particular MIME type in order to be properly interpreted. This is especially true in the case of compressed Javascript and CSS files. Adding the following lines to your .htaccess file immediately following the above rules should take care of this problem.

Some persons may get a bit more creative and decide to serve files that are pre-compressed. By “pre-compressed”, I mean that they take their CSS file, for example, and use a program such a 7Zip to output a GZipped version, in the same way one would Zip a file for local archiving. Referencing mystylesheet.css.gz in the HTML’s header will not be sufficient as the web browser requires additional information in order to read the GZipped content. Append your .htaccess file with the following lines:

Additionally, do not forget to specify the MIME type for the CSS call in the HTML’s header.

These additional .htaccess statements force browsers to interpret .css.gz and .js.gz files as CSS and Javascript respectively. Safari and old versions of Internet Explorer have problems with this so additional statements have to be made for them. You will notice that their User Agents are mentioned within the 3rd and 4th lines of the .htaccess rules above.

While serving pre-compressed files can save you a lot of bandwidth and speed up website loading, compatibility across different browsers (and different versions of a single browser) may pose a problem. There are bound to be browser User Agents that will not be able to interpret your .css.gz and .js.gz files. Here is where checking your website’s appearance through multiple web browsers comes in handy. Should you use Google Analytics, you can easily pin-point those popular web browser clients coming to your website and determine whether or not compression will hurt your visitors’ experience.

E. Test for compression

There are several tools out there that you can use to see whether or not your website content is being served compressed. Two of my favourite are Site-Perf.com and GIDNetwork.com. Simply enter your website’s URL and run the test. If compression is working properly, you will notice compression ratios being reported for the various elements on the web page.

Sample test report after GZip activation

F. Final words

I hope this article has been helpful to you. If you find problems and have suggestions, please mention them in the comments. In Part II of this series, I will share with you my experience using PHP to compress website content when you do not have access to activating it via php.ini. Hopefully, that one should be much shorter!