Speed up your pages. Use less bandwidth. - GoFuckYourself.com

jayeff · 02-18-2007, 10:58 AM

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:

Code:

<?php
$file = $_SERVER["PATH_TRANSLATED"];
readfile($file);
?>

Save this code to a file called begin_gzip.php:

Code:

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

Save this code to a file called end_gzip.php:

Code:

<?php ob_flush(); ?>

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:

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

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.

Boobs · 02-18-2007, 11:02 AM

some really techie stuff here

jayeff · 02-18-2007, 11:31 AM

Quote:

Originally Posted by Boobs

some really techie stuff here

It's actually about as complicated as following the instructions on a packet of Jello. But yes, I don't imagine this is a thread which will stay on the front page for long

RawAlex · 02-18-2007, 11:36 AM

of course, you could just move on to apache2 and stop worrying.

It would also be interesting to see what the implications are of this strategy on CPU usage. It would appear that you are handing your server a ton of processing work to do to keep serving pages. At what point do you run out of processing before you run out of bandwidth?

Calvinguy · 02-18-2007, 11:48 AM

Can external css files be compressed in some way?

tASSy · 02-18-2007, 11:50 AM

Quote:

Originally Posted by RawAlex

of course, you could just move on to apache2 and stop worrying.

jayeff · 02-18-2007, 12:00 PM

Quote:

Originally Posted by RawAlex

of course, you could just move on to apache2 and stop worrying.

Apache2, like the most recent versions of mySQL and to a lesser extent, PHP, tend to solve some problems while introducing others: at least until everyone catches up with them. For that reason, I must admit I tend to upgrade underlying stuff slowly.

Quote:

Originally Posted by RawAlex

It would also be interesting to see what the implications are of this strategy on CPU usage. It would appear that you are handing your server a ton of processing work to do to keep serving pages. At what point do you run out of processing before you run out of bandwidth?

Gzip has been shown to be an efficient process and if you think about the whole cycle of delivering content, not merely about the actual compression, using gzip isn't all downside. A lot will depend on what else is in the mix, but as I noted originally (and one of my test servers is a very humble P3) I haven't seen anything negative so far and I suspect you would already be close to overloaded for the extra work this generates to become critical.

uno · 02-18-2007, 12:19 PM

will that work in conjunction with mod_gzip?

jayeff · 02-18-2007, 12:31 PM

Quote:

Originally Posted by uno

will that work in conjunction with mod_gzip?

No idea. I specifically wanted to avoid mod_gzip although somewhat embarrassingly, I can't even remember why now. Anyway I checked it out first and there was at least one of the requirements I mentioned in my first post, that it didn't meet.

The main thing is this takes a couple of minutes to set up and as long as it takes to delete those lines from htaccess, if it doesn't work and no damage done.

NoWhErE · 02-18-2007, 12:35 PM

Do you think we could apply that to GFY? Things are loading so slowly lately :P

rotterdammer · 02-18-2007, 12:37 PM

very cool tips you are telling her

fuzebox · 02-18-2007, 01:22 PM

Quote:

Originally Posted by jayeff

Apache2, like the most recent versions of mySQL and to a lesser extent, PHP, tend to solve some problems while introducing others: at least until everyone catches up with them. For that reason, I must admit I tend to upgrade underlying stuff slowly.

I'm the same way, every time I try to go with Apache2 on a new box it lasts for about a day before I get frustrated and go back to 1.3.

Phil21 · 02-18-2007, 02:04 PM

Regarding the CPU use comment...

On 95%+ of all dedicated servers (likely more, but I don't care to try to filter statistics on a sunday afternoon...) CPU is basically idle. Customers have unfortunately been duped by crap marketing from hosting providers basically telling them MORE BIGGER BETTER with regards to CPU, and thus we have to compete in that arena (even though during pre-sales, we absolutely try to point out that the dual xeon for your 2mbit of traffic is likely overkill).

In almost all cases, your largest bottleneck will be disk I/O. Period. Gzip in this manner helps with that, as the files are smaller. mod_gzip trades cpu use for bandwidth savings - so it's a tradeoff you have to decide if it's worth it or not.

That said... If you can use mod_gzip instead of this solution - do so. It will be a huge savings in CPU, probably by a factor of 10 or more. However, as Jayeff mentions mod_gzip doesn't play nicely with some applications making this a great solution for those PHP pages that you otherwise couldn't gain bandwidth savings on.

Good post!

02-18-2007, 10:58 AM	#1
jayeff Confirmed User Join Date: May 2001 Posts: 2,944	Speed up your pages. Use less bandwidth. 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: Code: <?php $file = $_SERVER["PATH_TRANSLATED"]; readfile($file); ?> Save this code to a file called begin_gzip.php: Code: <?php ob_start("ob_gzhandler"); ?> Save this code to a file called end_gzip.php: Code: <?php ob_flush(); ?> 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: 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 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.

02-18-2007, 11:02 AM	#2
Boobs Confirmed User Join Date: Aug 2006 Posts: 7,875	some really techie stuff here __________________ Join the fucking best in big tit sponsors!!!

02-18-2007, 12:19 PM	#8
uno RIP Dodger. BEST.CAT.EVER Industry Role: Join Date: Dec 2002 Location: NYC Area Posts: 18,450	will that work in conjunction with mod_gzip? __________________ -uno icq: 111-914 CrazyBabe.com - porn art MojoHost - For all your hosting needs, present and future. Tell them I sent ya!

02-18-2007, 12:35 PM	#10
NoWhErE Too lazy to set a custom title Industry Role: Join Date: Sep 2005 Location: Canada Posts: 10,492	Do you think we could apply that to GFY? Things are loading so slowly lately :P __________________ skype: lordofthecameltoe

02-18-2007, 12:37 PM	#11
rotterdammer Confirmed User Join Date: Feb 2006 Posts: 1,523	very cool tips you are telling her __________________ My Best Sponsors: 1 2 3 4 5 6 7 8 9 10 Im Making Over $1000 / Month With OrgyCash! Get Inside Now! - Big List Of Domains For Sale!

02-18-2007, 11:36 AM	#4
RawAlex So Fucking Banned Join Date: Oct 2003 Location: In a house. Posts: 9,465	of course, you could just move on to apache2 and stop worrying. It would also be interesting to see what the implications are of this strategy on CPU usage. It would appear that you are handing your server a ton of processing work to do to keep serving pages. At what point do you run out of processing before you run out of bandwidth?

02-18-2007, 11:48 AM	#5
Calvinguy Confirmed User Join Date: Oct 2002 Location: European Union Posts: 1,752	Can external css files be compressed in some way?

02-18-2007, 02:04 PM	#13
Phil21 Confirmed User Join Date: May 2001 Location: ICQ: 25285313 Posts: 993	Regarding the CPU use comment... On 95%+ of all dedicated servers (likely more, but I don't care to try to filter statistics on a sunday afternoon...) CPU is basically idle. Customers have unfortunately been duped by crap marketing from hosting providers basically telling them MORE BIGGER BETTER with regards to CPU, and thus we have to compete in that arena (even though during pre-sales, we absolutely try to point out that the dual xeon for your 2mbit of traffic is likely overkill). In almost all cases, your largest bottleneck will be disk I/O. Period. Gzip in this manner helps with that, as the files are smaller. mod_gzip trades cpu use for bandwidth savings - so it's a tradeoff you have to decide if it's worth it or not. That said... If you can use mod_gzip instead of this solution - do so. It will be a huge savings in CPU, probably by a factor of 10 or more. However, as Jayeff mentions mod_gzip doesn't play nicely with some applications making this a great solution for those PHP pages that you otherwise couldn't gain bandwidth savings on. Good post! __________________ Quality affordable hosting.