Jun 12, 2009

Does gzip compression speed up or slow down your web site?

Gzip is a good way to make your web site faster. It may decrease the size of downlodable documents by half. This seriously speeds up the loading of the site because network delays affects the performance (and user satisfaction) most.

But there is a drawback of the gzip compression that many people do not realize.

In the early Apache 1.x days mod_gzip had a very nice feature: file cache for the compressed content. mod_deflate in Apache 2 does not have any caching for the compressed content. It means that downloading 500KB of ExtJS with compression means compression this file each time. If there is no client cache or mod_proxy, this becomes a major problem. It seriously increases the load on the server. Also it slows down the response time because the file has to be compressed each time. It is a serious issue to consider for large web sites. Even client caching is not a solution.

The solution that I use for such cases is a pre–compression of such files. Then I use a mod_rewrite checks and rules to rewrite requests to these files to their compressed versions. It speeds up the loading (by 1-2 seconds in case of ExtJS).


  1. I totally agree - always wondered about those cpu load issues when reading about ySlow's suggestions concerning gzipping.

    Dmitry - how would such a rewrite section look like? And you you compress eg the ExtJS file yourself before?



  2. Instead of pre-compression and mod-rewrite rules you could put a gzip-aware caching proxy in front of the web server.

    This resolves the gzip problem and obviously has further advantages.

  3. Jochen, Yes, I pre-compress all js/css for all sites now.

    Marcus, proxy means extra CPU too and I'll have to create rules to skip caching pages. I expect that precompressed files + mod_rewrite will be faste, more robust and easier to setup.

  4. I'd recommend to review Markus' suggestion from a more complete perspective:

    As to our experience a gzipping and caching proxy will eg. offload +70% from the real webserver, for the cost of max 15% of CPU/MEM.

    However the benefit and metrics, as always, depend on the nature (templating, caching...) of the instance.

  5. This can only be determined by testing in a real world situation. Where is the data to support these claims? How long does it take to compress the 500K file? Is the cached file not cached in the webserver memory?

  6. Use lighttpd has this by default.