A website developer should always strive to provide a better user experience, with a combination of a design and layout where the information the end user seeks is easily available and a performant site so the user is not experiencing the World Wide Wait.

An engineer deals in terms of tradeoffs. With Moore’s Law showing no sign of relenting, increasing CPU performance both at the server side and client side is a given. In our case, we can easily switch to a dual-core Opteron by just replacing the processor chip and flashing to a new bios and we have an SMP system with the same physical dimension.

However, the other aspect impacting performance is that of bandwith. Inspite of growing broadband usage, the majority of our user base particularly that from the subcontinent and Africa connect to the Internet via dial-up connections typically at speeds ranging from 28.8 kbps to 56 kpbs (kilo bits per second). This translates to 3.6 KB/s to 7 KB/s (Kilo Bytes per second)

With typical web-pages being of around 40KB (kilo-bytes) and at times even reaching upto 100 KB, this translates to a wait time of 10 to 30 secs for a 28.8 kbps modem user which is very long.

Is there any thing we can do to improve the situation ?

Yes, designers of the HTTP protocol (HTTP is the language spoken between web browsers and web servers) created a mechanism whereby browsers could request for content to be compressed before being sent to it and it would decompress it in real-time and render it for the user. This is negotiated via the Accept-Encoding: gzip,deflate header sent by the browser and the Content-Encoding: gzip response header sent by the server.

Apache 2.0 provides the deflate module and Apache 1.3 provides the gzip module.

We are very excited to offer this functionality in our new infrastructure. Our initial tests show that content is compressed on average by around 65% percent so for a page which was 40KB without compression would be around 14 KB with compression. Thus for a 28.8 kbps user the time to view the page drops from around 12 seconds to 4 seconds and the viewer feels like visiting the site over and over again.

We expect HTTP compression to be very useful as our userbase moves to an always connected environment via cellular networks such as GPRS