One of the core components of an application acceleration solution is almost always compression, and almost always implemented using industry standard algorithms supported by the ubiquitous browser.

Compression is used as an application acceleration technique to decrease the total amount of data that needs to be transmitted, thereby reducing the total number of packets that must traverse the network. This results in an overall decrease in the amount of data and protocol overhead required which ultimately means the client gets the data faster.

Developers and architects might be thinking: "Hey, my web/app server can compress content, I just have to flip this bit here in the configuration." And they'd be pretty much right. Compression itself is not rocket science, it's been around for years and is widely supported. What is tricky is determining the most efficienct application of compression, because in some situations compression can actually result in slower application performance.

Wait...what? Yes, you read that right. The technology designed to improve performance can actually degrade performance in some situations.


In order to determine whether compression will improve or degrade application performance you need to consider a number of factors, each of which has an effect on whether or not compression will help or hinder performance.

Type of Content
Some content was just made to be compressed, while other content may not benefit from compression at all. Attempting to compress content that will not benefit from the action is a waste of time and resources, and can result in a net negative.

  1. Encrypted Content
    Encrypted content is binary and therefore any benefit derived from compression will be minimal; unless the application acceleration solution can apply compression before the content is encrypted, in which case you'll see definite benefits.
  2. JPG (and other binary content)
    Some binary content, especially JPG images, are already compressed and thus additional attempts at compression is a waste of time.
  3. Text (XML, D/HTML, CSS, JavaScript, etc...)
    Text based content and data formats derive the most benefit from compression. Text-based formats can always be reduced in size using compression, and given the increasingly large size of pages this is one of the best ways to improve the performance of a Web 2.0 site. But remember that some agents (browsers) have issues with compressed JavaScript, and therefore JavaScript cannot always be compressed.

Type of Client Connection
The bandwidth capacity of the client's connection is one of those factors that is often overlooked. The general rule is that the slower and smaller the pipe to the client, the more benefit that will be seen from compression. A LAN-connected client may actually see a degradation in performance if compression is used, because the time it takes to apply compression to the data is longer than it would take to just serve up the content raw across the network.

  1. Dial-up
    Dial-up connected clients (yes, they still exist) will almost always benefit from compression due to size and speed limitations imposed by the modem.
  2. Broadband & WAN
    Broadband and WAN connected clients may benefit, but as the definition here varies widely in regards to size and speed the decision to compress or not compress will require a bit of testing.
  3. LAN
    It is almost always the case that a LAN-connected client will not benefit from compression and that the act of compression will, in fact, make things worse.

Type of Agent
When deciding whether or not to compress the type of agent requesting the content should also be taken into consideration.

  1. Spiders/Crawlers
    Spiders/Crawlers may or may not support compression, and it may be considered a waste of resources to apply compression for these particular agents. After all, is it important to serve content quickly to an agent that doesn't care?
  2. Browsers
    Browsers generally represent real, live people (i.e. customers) and therefore browsers should be treated as though there are always real-people behind them who desire - no, demand - a good user experience. And of course a good user experience means fast. While the major browsers (IE, Firefox, Netscape, Opera, Safari, Konqueror) all support compression, there is a growing number of mobile browsers that do not - so beware.

So Should I Enable Compression or Not?!?

The answer to whether or not you should enable compression is entirely up to you. But it's likely that simply enabling compression will cause problems for as many clients as will see a benefit. The problem is that a web/application server cannot take into consideration the aforementioned factors and apply compression on a dynamic, case-by-case basis. And that, in a nutshell, is what it really takes in order for compression to be a successful application acceleration technique.

The answer is difficult because compression is no longer a binary proposition - it isn't just on or off. Compression is still one of the best ways to improve application performance - but only when it's applied in those situations from which the user will benefit, and the only way to determine which users will benefit is to evaluate the factors in real time.

This is one of those areas in which an application delivery solution shines, because it supports the ability to intelligently apply compression when it will benefit the user, and only then. By deploying an application delivery solution you get the ability to apply compression intelligently across all websites and applications at the same time, without making any changes to the application or servers.

Imbibing: Coffee