Just to make sure we're all being clear on this, gzip is not the same thing as zipping a file. Similar maybe, but not the same. We're talking HTTP Compression here, not actual file compression. Technically what we're talking about is known as Dynamic Content Encoding, which just means the compression or encoding happens when the file is requested, not when the file is uploaded.
To make it more confusing, this stuff is handled at the server configuration level. As a webmaster you don't do anything special with your files when you're uploading them, the compression just happens if the server is configured to support one or more of the various methods of compression.
And to make it even
more confusing, there are several different ways to provide compression.
The two main Apache modules are mod_deflate and mod_gzip. They're similar but not the same.
And there are also alternative ways to provide compression that are language dependent. For example, PHP provides ob_gzhandler and zlib output compression. You can use one or the other, but not both.
Limiting ourselves for the sake of sanity, the differences main differences between Apache's mod_deflate and mod_gzip are:
- mod_deflate comes pre-installed and enabled in recent versions of Apache. mod_gzip doesn't, meaning you'd have to recompile Apache to have it available if it's not already. Many hosts do compile Apache with mod_gzip support, but not all do. So it may or may not be an available option. (You can see this in the Loaded Modules section for Apache's handlers in a standard phpinfo(); page.)
- mod_gzip will offer a higher compression level than mod_deflate, meaning lower bandwidth usage and faster file delivery.
- mod_gzip carries a slightly higher server load effect than mod_deflate.
And the main differences between PHP's zlib and ob_gzhandler methods are:
- zlib.output_compression runs parallel with the php script execution, meaning it begins compressing as soon as it receives any output from the script, sending chunks of data to the client each time it reaches its preset buffer limit is reached. That's chunks of data 4k in size by default.
- Conversely ob_gzhandler does not start compressing the data until the script "flushes", which usually means the script has exited, and will then send the entire compressed document all at once. It's this wait until the end trait that can make ob_gzhandler seem slower for very large files, because nothing at all shows up on the screen until it's all finished.
- ob_gzhandler allows you to set the level of compression at run time, or if you don't tell it a level explicitly it'll use its default compression level.
- ob_gzhandler benchmarks show a slightly higher CPU load quotient than zlib, but it's not a huge difference.
In most cases it doesn't matter much which compression routine you choose to utilize. The differences are small enough as a general rule that it just doesn't matter. What can matter however is if HTTP compression is happening or not.
Side note: Older browsers, especially old versions of Netscape, IE5 and even 6 used to sometimes have issue with compression but that's pretty much a non issue these days. The problem was they'd send a header saying they could handle compressed/encoded files when they didn't. Those bugs have been wiped out in all modern browsers.
Another side note... This all is
only dealing with Text Compression. It has nothing to do with image compression. Images and other binary files should already be compressed before they're uploaded.
Do I have my servers configured to automatically utilize compression? Yes I do. I try to keep things pretty normal these days since it's the easiest to do and there aren't any huge advantages for taking extra steps. So long story shorter, I have Apache set up to use mod_deflate that comes as a pre-installed module and have my php.ini set up to enable zlib.output_compression. Then if I need better compression or need to control the level of compression of a single file I start ob_gzhandler, which I also have compiled into PHP via the Zend stuff.
Does it make a difference? Yes it can and does. Both in page load speed and in bandwidth usage. The latter being the bigger reason why I enable compression by default. It's not at all unusual for basic compression settings to cut the file size / bandwidth usage for delivery of a file by 50-60%. On those sites where I have enabled ob_gzhandler by default (via an .htaccess instruction that says
php_value output_handler ob_gzhandler since it's already compiled into php and available) it's not at all unusual to see compression levels of 70-75%.
So your #1 recommendation is something one could write an entire book about.
There is no single best answer. It depends. Sometimes no compression is just fine. Most times some form of compression is better, but you need to choose the one that best fits your specific situation.
