tags:

views:

149

answers:

3
+2  Q: 

gzip or not gzip

I keep hearing that gzip your site is a good practice to speed-up delivery. My site has a very vast load in general, shall i still look into gzip? I also read about disadvantages of using gzip, such as time required to unzip contents for the browser to display. Is it true?


UPDATE:

This question is based on the assumption that the site is fairly optimized already.

Actually I optimized it already. Most of the content on my site is db driven and originally it took some time to load it all, so what I did, I wrote a few scripts that run nightly, generate content and store it as static HTML files that are included on the heaviest trafficked pages. The load on the server is way below its capacity, so, thank you for that insight, I will consider it more seriously now. I was thinking of using some PHP class that does it dynamically. Do you have any recommendations?

+6  A: 

Compressing your response will help with transfer times. That means it will decrease the time it will take for the user to download the generated page. It will not (in general) reduce the load on your server. In fact, it can increase it slightly since compression itself is not free (it eats up some CPU cycles).

Typically, there's no disadvantage from a user experience (only advantages).

However, if your server is already heavily loaded, I'd probably skip it since it will only add to that load (in general). Optimize the code first, then add compression. Don't try to add compression as a band-aid for poorly optimized code (it won't work)...

ircmaxell
*Optimize the code first, then add compression.* - I beg to differ. Optimization is a time-consuming (=expensive) task which doesn't necessarily give desired results. Gzipping is a simple measure which only costs you about half an hour of configuring your server and then some CPU cycles for guaranteed results. Even for high-load sites, I'd say the reduced bandwidth is well worth any CPU cost (I/O is slower than CPU).
gustafc
@gustafc: Fair enough. But the thing to realize is that it's not free. And with modern Linux kernels and asynchronous I/O provided by most modern web servers is quite efficient (in terms of CPU cost for longer transfers). Sure, there will be some gain by adding compression, but it depends on your loading whether it's going to help (If you're CPU bound, it'll likely hurt you to compress. If you're disk or I/O bound, it'll help). It all depends what state your CPUs sit in most of the time...
ircmaxell
I would suggest either using [mod_deflate](http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/) (if you're using Apache) or PHP's built in [ZLib Output Compression](http://us.php.net/manual/en/zlib.configuration.php#ini.zlib.output-compression). They do a lot of checks for supported browsers, etc. There's no real need to do it in PHP if you don't have to (meaning if you can edit a `.htaccess` file, or `php.ini`)...
ircmaxell
Thanks, I'll check these. Yes I have full access to all files on my dedicated server.
santa
@ircmaxwell - *If you're CPU bound, it'll likely hurt you to compress.* Yeah, sure, but when did you last run across a CPU bound web application?
gustafc
@gustafc: More often than you'd think. Usually due to bad SQL queries (Cartesian joins typically) or tight loops that don't need to be there. It's especially common on budget hosts that use commodity processors (Centron/Centrino and Sempron processors) instead of server grade hardware...
ircmaxell
+1  A: 

Hi,

I agree with @ircmaxell. You should try to optimize your app - if the database is poorly optimized or there are silly queries it will not do any magic for you. On the contrary you can not loose anything - the CPU will suffer from some additional load but it could severely decrease you bandwidth usage. Due to most modern browsers support GZIP compression it is only about the server asking client whether his browser support it. More info http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

Maybe you should also try to use it with some of the caching modules as suggested @Andrew Sledge. Try APC :-) http://www.php.net/manual/en/intro.apc.php. Also try to compress css files, images or js files. I used to generating the whole web statically and then updated only changed pages - it definitely depends on the update rate..

Bery
Technical point. The server does not ask the client whether the client supports http response-entity compression. The client will instruct the server, in the `Accept-Encoding` header of each http request, which encoding/compression schemes the client supports and in which order of preference, and the server will use that information to determine which, if any, encoding/compression scheme to use to encode/compress the http response-entity.
Justice
@Justice: According to [HTTP 1.1 Spec](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), `If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding`... But if the header is present, it should be respected...
ircmaxell
You are right. My fault. The client tells the server...
Bery
@ircmaxell, you are right, that is the spec. Of course, if I were charged with writing the spec, and if I didn't care about backward-compatibility with HTTP/1.0 and compatibility with existing implementations, my rule would be different. But I'm not, so it isn't.
Justice
@Justice: You have no argument from me. I was just pointing out that if the header isn't there you are technically free to do what you wish. But you are correct that you should respect it if it exists (which is why I recommend using a built in mechanism so that you don't need to worry about it)...
ircmaxell
+1  A: 

You should gzip your content because:

  • it easy very easy to do.
  • it saves you bandwidth(which could save you money).
  • it will make your site faster. You are right about that it takes a little bit time to unpack gzip, but still it is going to be faster because less data has to be downloaded.

You should also read the part about gzip from yahoo's best practices.

Alfred