Intel Blows Bandwidth

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The Web site of the Intel Corporation is wasting more Internet bandwidth
than any other major company, according to a new study of
all
Fortune 1000 corporations.

The report found that the Intel site could reduce by

82% the number of bytes it sends out to visitors. The change would merely
require adding a simple data-compression method that’s been an Internet standard
for years.

I guess if you sell a lot of chips, you can blow a lot of bits.
(Intel didn’t respond to e-mail requests for comment.)

It’s very likely that your own corporate site, though, isn’t doing much
better than Intel’s. Fewer than 3% of the Fortune 1000 are using the
recommended performance-enhancing technique, according to the study, which was
prepared by compression-utility vendor Port80 Software Inc.
The authors of the report estimate that large companies can save an
average of 25% of their sites’ bandwidth bills — representing
millions of dollars — by making one minor change.

The Unknown Standard: HTTP Compression

That change involves an Internet specification known as HTTP compression.
This technique has been a standard since HTTP 1.1 was approved by the
World Wide Web Consortium
(W3C) in 1999.

Every modern Web browser, starting with Internet Explorer 4.0 and Netscape 4.0,
supports HTTP 1.1 and therefore HTTP compression, according to Joe Lima,
Port80’s director of product development. The technique is already used by such
well-known sites as Amazon.com, Google.com, and Yahoo.com. But the
other 97% of enterprise sites are missing out on the cost savings they could
be reaping.

That’s a shame, because HTTP compression is easy to add to a Web server.
It can even be implemented for free, in many cases.

Pick Your Server

Different Web servers require different tools. The servers most
widely used by the Fortune 1000 — and their prospects for compression
— are:

• Apache. A number of free HTTP compression utilities are
supported by Apache, the popular open-source server software for Unix.
The programs most commonly used are known as
mod_gzip and
mod_deflate.

• Netscape Enterprise Server. Software products are
not currently available to add HTTP compression to Netscape’s
server. This has helped create a market for hardware-based compression
appliances, which also work with other server types. Packeteer Inc.’s
AppCelera,
Vigos AG’s Website Accelerator,
and Redline Networks’ E|X
3250 are three such devices. These are high-end solutions that can cost
$20,000 and up.

• Internet Information Server 4 and 5.
Microsoft’s IIS 4 and 5 servers include HTTP compression tools,
but they suffer from many problems. The most prevalent complaints are that the
utilities have maddening bugs and support only static, not
dynamic, content. Numerous software add-ons to IIS exist, including Port 80’s
httpZip (around
$300), ObjectsFarm’s TurboIIS ($500), and
XCache Technologies’
xCompress
($400).

• Internet Information Server 6.
IIS 6, by all accounts, has

improved its HTTP compression tools so much
over the ones found in IIS 4 and 5 that add-on products are not needed
for this version. IIS 6, however, is bundled with Windows Server
2003, which is not yet widely installed by corporations.

An excellent technical paper on switching a server over to HTTP compression is
provided by
IBM DeveloperWorks. This 12-page report not only describes the best
approaches to the switchover, but also covers a tweak that’s necessary for
the IBM HTTP Server, a near-clone of Apache that’s incompatible with mod_gzip.

Avoiding Trouble Spots with Compression

Like anything that has to do with computers, HTTP compression offers great
benefits but isn’t 100% trouble-free. You must, for example, ensure that the
tool you use sends some Web content across the wire in its original,
uncompressed form.

Port80’s Lima says the following content isn’t compressed by his company’s
utility, and tools such as mod_gzip should be configured the same way:

• JavaScript.

• Cascading Style Sheets (CSS), when delivered to Internet
Explorer browsers.

• Images, except .bmp files delivered to IE.

• Audio files, except .wav files.

• Message MIME types, except RFC 822 subtypes.

As a final “gotcha,” businesses that use a Web-hosting service (as my own
company does) may discover that its policies don’t permit server-side compression.

Conclusion: Thou Shalt Compress or Pay the Price

HTTP compression is an idea whose time may have finally come. Its implementation
requires adequate study and testing — but when the payback can be a 25% cut
in your enterprise’s bandwidth invoices, I think the learning curve is worth it.