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 i开发者_如何学Got 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?

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)...

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.

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..

I'm aware this is an old stack question, but figured I'd try to answer your question in today's terms / best practices.

Since you are making static files nightly I'd suggest looking into zopfli compression of the static files here's the php lib. Particularly because zopfli compression is about 5% more compression than standard gzip, and it doesn't need to be done each time (you do it once when the static file is generated and store it that way). Then you can serve up the gziped file when requested by users that support gzip (you don't need on the fly compression that way). For the users that don't support gzip you can gunzip it on your server (this reduces I/O since the zipped file is smaller than the unzipped version, essentially its on the fly decompression).

You should still use on the fly compression for dynamic content though (not zopfli, because it has a higher time / cost).

As far as time cost is concerned with regards to zopfli zipping the static content: As long as it is accessed more than 100 times a day it is worth doing, since it takes about 100x more processing power than standard gzip. So once you hit 101 your processor will have officially done less processing than on the fly compression of it.

Time required to unzip the content is alway fraction to what you will save with transfer time.