PHP file compression

First off check to see if your webserver already serves the pages compressed.

At the risk of sounding dense, how do you do that?

Check the page's response headers, look for "Content-Encoding: gzip"

With Firefox, Web Developer/Information/Response Headers.

Or send the url to www.websiteoptimization.com for a speed report (on FF, Web Developer/Tools/View Speed Report) ...

or

# This site is not using HTTP compression, otherwise called content encoding using gzip. Consider compressing your textual content (XHTML, JavaScript, etc.) with mod_gzip or similar products.

Note that this speed report can sometimes be misleading as it includes and calculates every image referenced by your css stylesheet, whereas the page you are sending may only call a few of those images during rendering.

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

Unless I'm being a bit thick, this is a bit misleading as ob_gzhandler() and its related functions deal with the sending of compressed data to the browser, not the compression of scripts for storage on the server. There are various ways of compressing and semi-compiling (for want of a better term) php scripts, but these involve additional modules and libraries, and are normally used to speed up script run-times (I keep meaning to look into these things in depth, but never seem to find the time!). Also, whilst on the subject of serving compressed files, I seem to remember reading somewhere that IE has a bug (surprise, surprise) whereby it will not cache pages delivered as compressed gzip files. Me thinks this could slow up the user's experience in some circumstances.

Using that PHP script I posted above shows huge differences on www.websiteoptimization.com!
For instance, my own design site is done in ASP with no compression and the speed report listed 49 different objects on the home page (which as you say Roy is all the CSS background images).
A page which I've done for a client in PHP using the script and hosted on the same server comes in at about 40x smaller and only lists 3 objects: the HTML, CSS & a javascript file. It doesn't list any images at all, even though there are at least 7. Admittedly, the actual file sizes for the HTML & CSS are smaller as it's only a single page at the moment, but it's still a huge difference.
I don't s'pose anyone knows of a method to employ gzip encoding using ASP? I've had a look but everything seems to point to configuring IIS which, if I'm understanding correctly, is already done so for IIS6.
I don't really want to convert all my pages to PHP. :?

Found a more detailed article about gzipping your CSS.

Something else I've just discovered: on my site I've got a piece of javascript to serve up a version 4 stylesheet. With that code in, the speed report tells me that the page is 240k and keeps showing repeat entries for background images even though the v4 stylesheet has nearly no background images. If I take out the javascript, the speed report says the page is only 10k! (In both cases, I'm linking to a php css file using ob_start ("ob_gzhandler") as describd in the above article).

I've never trusted the speed report, preferrring to use a combination of testing and experience. Neither do I use mod_gzip, but I'm certainly going to look into it now

Let us know if you find any downsides cos I found quite a few articles extolling its virtues but as I'm not that familiar with PHP, would like to know if I'm missing anything important.

Well, I've found a downside already. :? I created a test ASP page which pulls in a PHP CSS file and it works fine in FF & Opera, but IE doesn't have any styling. :roll:

I didn't have too much time to spare yesterday (do I ever!) but I read some of these pages and started to have my doubts about the downsides:

http://www.schroepl.net/projekte/mod_gzip/

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:28156312813364

Then I contacted a couple of experienced colleagues who help me with my servers and one said that I might notice the CPU overhead. The other said that it's not compatible with http/1.0 and that the overhead generated can be considerable. He said that it has rendering effects such as the entire page needing to be downloaded before display, and added that often the crypt/decrypt overhead is harder and slower than the download time saving over modern broadband links.

It seems that it was worth the trouble in the days of dial-up where the download size was a significant bottle neck, but that with the way things are moving today, it's just not worth the risk of running into problems with IE (as you've just noticed).

As for ob_gzhandler, if you read the user notes there are a few negatives worth noting:

http://uk2.php.net/manual/en/function.ob-gzhandler.php

All-in-all, as I run mission critical applications and ecommerce sites on my servers, I am not going to take this any further. Let me know if you stick with it as some high-profile sites like Slashdot seem to do okay with it.

fyi - apache 2.0 can use mod_deflate, apache's own compression module. mod_deflate does address a number of the concerns outlined in the article in Roy's first link, including:
- compression level is configurable
- what and for whom output should be compressed is configurable (incl. file types, proxy servers, browser types).

TBH, I think mod_gzip can be set up to in pretty much the same manner at least under apache 1.3.

For those that are interested in more of the background, read this post by what looks to be the same Michael who supports the mod_gzip documentation (Roy's first link).

There is also a comparison of apache 1.3 and apache 2.0 which also in affect compares non-compressed with compressed output. Obviously the raw figures only apply to one particular configuration on one particular PC. What I read out of it.

• apache serving uncompressed plain html files was able to achieve a throughput in the low '000s of requests per second at a transfer rate around 20MB per second (that's 160Mbit).
• apache serving compressed plain html files was able to achieve a throughput in the low '00s of requests per second at a transfer rate of around 1Mb per second (8Mbit).

What I read out of this is whether or not you use a compression module depends on the bandwidth available to you. If your server has access to a connection in 100Mbit+ range you'll be better off not using compression. If its in the 10Mbit- range you'll be better off using compression. In between you'll probably need to do your own tests.

If you have a data transfer limit and/or usage charging you'll want to take those costs/savings into account too.

That test was done on a Celeron 1Gig/768MB. If your server is running an Athlon 64/mucho GB you may reach different conclusions. Also that was plain html - not dynamic content.

Please take my analysis and conclusions with scepticism. If this is really important to you consider having an expert profile your server and its throughput with a fair sample of your own likely traffic.

Also you may want to read this - http://www.ilia.ws/files/phpworks_performance.pdf. The author of this and the comparison develops fudforum.

[/]

Thanks for looking into that and summarising it for us Chris. Personally, my servers are connected to 100Mb unrestricted networks so I think I'll pass on the compression route and save myself the hassle of configuration and testing.

There's a section on that site about firewalls and how some of them behave differently with mod_gzip.
Well, the test ASP page I was talking about above that doesn't work in IE - it works in IE at home where I've got a software firewall, but not at work where we've got a hardware firewall. However, both behave the same if it's a PHP page calling a PHP CSS file. Weird. :?

Its not quite that they behave any differently. Its that they overwrite/mangle a particular http header. A header that is crucial to your browser recognising the http content is compressed. Uncompressed pages don't have that header.

If you use Firefox you should be able to check by viewing the page headers (web dev/information/View Response Headers). Content compression has been around for a few years now, its not a little sad if some firewalls still behave in that manner.

It's probably cos, like everything else in this office, our firewall is ancient.