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
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.
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.
[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
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 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.
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.
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!