A client just installed this on his site and reported a 42K (80%) reduction in the data delivered when visiting his main page. That makes for faster load times and a major bandwidth saving.
This method utilizes gzip which is available by default on most servers these days. It can be used on any type of site, but since images are not gzipped, the main benefit is for sites using lots of text and/or code. Blogs are obviously prime candidates and also the reason I went this route rather than mod_gzip. It causes problems with WP-Cache, as does telling WordPress to deliver gzipped pages.
I also wanted a solution which would gzip all the pages on a site, not only php pages generated by WordPress, but also static HTML pages. I did not want to have to add code to every page. And I didn't want any problems with Zend. This appears to satisfy all those conditions.
Save this code to a file called compress.php:
Save this code to a file called begin_gzip.php:
Save this code to a file called end_gzip.php:
FTP all three files to your root directory and then modify the paths in these lines and add them to .htaccess in your root directory:
That's it. Go to http://whatsmyip.org/mod_gzip_test/ put in your site URL and see if it is working.
I have tested this on several sites for more than a month, primarily sites using WordPress 2.1 and WP-Cache2, plus a variety of other plugins and scripts. The only glitch seems to be with scripts such as Comus which have slow-running routines for things like creating thumbnails. What happens is that you click the button to begin the process and you will not see an intermediate page (telling you the work is in progress). Everything functions as it should, but you will not see anything until the next page comes up when the job is complete.
As far as your surfers are concerned, the site runs normally and there are no browser incompatibilities. If an old browser doesn't understand gzip, it simply gets "regular" code and text. There may be a very small-payoff in processor load, but unless your server is close to the edge, nothing that will make any practical difference.
If you follow the instructions and it does not work, beyond checking that your server has gzip (plain gzip, not mod_gzip) enabled, I should assume you are using something it doesn't like and give up. But it will only take 5 minutes to find out and if all is okay, the savings can be significant.
This method utilizes gzip which is available by default on most servers these days. It can be used on any type of site, but since images are not gzipped, the main benefit is for sites using lots of text and/or code. Blogs are obviously prime candidates and also the reason I went this route rather than mod_gzip. It causes problems with WP-Cache, as does telling WordPress to deliver gzipped pages.
I also wanted a solution which would gzip all the pages on a site, not only php pages generated by WordPress, but also static HTML pages. I did not want to have to add code to every page. And I didn't want any problems with Zend. This appears to satisfy all those conditions.
Save this code to a file called compress.php:
Code:
<?php $file = $_SERVER["PATH_TRANSLATED"]; readfile($file); ?>
Code:
<?php ob_start("ob_gzhandler"); ?>
Code:
<?php ob_flush(); ?>
Code:
AddHandler compress .html Action compress /compress.php php_value auto_prepend_file /full_server_path_to_your_root_directory/begin_gzip.php php_value auto_append_file /full_server_path_to_your_root_directory/end_gzip.php
I have tested this on several sites for more than a month, primarily sites using WordPress 2.1 and WP-Cache2, plus a variety of other plugins and scripts. The only glitch seems to be with scripts such as Comus which have slow-running routines for things like creating thumbnails. What happens is that you click the button to begin the process and you will not see an intermediate page (telling you the work is in progress). Everything functions as it should, but you will not see anything until the next page comes up when the job is complete.
As far as your surfers are concerned, the site runs normally and there are no browser incompatibilities. If an old browser doesn't understand gzip, it simply gets "regular" code and text. There may be a very small-payoff in processor load, but unless your server is close to the edge, nothing that will make any practical difference.
If you follow the instructions and it does not work, beyond checking that your server has gzip (plain gzip, not mod_gzip) enabled, I should assume you are using something it doesn't like and give up. But it will only take 5 minutes to find out and if all is okay, the savings can be significant.
Comment