Last night I completed a bandwidth trifecta that reduced the overall bandwidth uses on three different types of pages to an average of 17% of what they'd been!
The first, and most obvious step is GZIP-ing pages, and this is where you'll see your biggest gain.
There are a few ways to do this, but the only one that works for me with my shared host is to enable ZLIB compression in the php.ini file. First, add this line to enable ZLIB compression:
zlib.output_compression = On
Then add this line to determine the amount of compression:
zlib.output_compression_level = 6
The value needs to be between one and ten. I chose six because it seemed to be a popular choice around the web. Choosing one still yields great results and would put less strain on your server.
It's worth noting that in my situation you must have a php.ini file in EACH DIRECTORY you wish to use compression in, so I used another script to create symbolic links back to the php.ini file in my root directory.
Next, you need to tell your server to not only compress PHP output, but to compress CSS and and Javascript, as well. I'm running Apache, so I did this by adding the following line to my .htaccess file:
AddHandler application/x-httpd-php5 .php .css .js
I had done this before and while it resulted in smaller files it also resulted in a longer load time. The culprit was /lib/javascript-mod.php. The problem was that the file tries to specify the content length header manually, so when compression is used the browser doesn't think it's reached the end of the file and it hangs, and hangs, and hangs... until it eventually times out. I fixed this by simply removing the content-length header directive from the file altogether. So you might want to keep your eyes peeled for other scripts that try to force content length.
Anyway, we've now got compression up and running on all PHP, CSS, and Javascript files. But now the CSS and Javascript are now being returned as an incorrect content-type, which may cause some weird behavior. Plus, our CSS and JS files are STILL more bloated than they need to be.
Once again, PHP comes to the rescue. We're going to add a small piece that will run immediately prior to the processing of a PHP page to determine what kind of file we're dealing with and how to handle it. To do this we will add a file I created called prepend-moodle-1.0.php. In my case I put it in an includes folder at my web root (I'm applying these compressions to all pages I server, inside and outside of Moodle). If you only use Moodle, the /local directory would be a good place.
Once you decide on the location, add to your php.ini file:
auto_prepend_file = /full/path/to/prepend-moodle.php
For .js, .css, and styles.php (Moodle's composite stylesheets) files we:
- Send the correct Content-type header
- Set cache controls and expiration dates and
- Minify the output (remove excess whitespace, comments, and other unnecessary characters) *
- Rewrite the minified page with new headers
* The methods used for minifying require PHP5
Version 1.0 of my prepend-moodle.php file is attached. Remove the version (-1.0) from the file name before uploading.
jsmin can be obtained at http://code.google.com/p/jsmin-php/
cssmin can be obtained at http://code.google.com/p/cssmin/
