Cutting Bandwidth Needs

[rogerd]

Here's a good example of WebmasterWorld synchronicity - I ran across the "build for slow guys topic the same evening I got a "we're gonna bill you for extra bandwidth" notice from one of my hosts. One site I manage is a victim of its own success, generating 25 GB of bandwidth usage last month.

A lot of the bandwidth comes from a discussion forum. These pages aren't graphic - at most, they load a gif banner. They are, of course, text-heavy. So, I'm looking for ways to cut down on bandwidth usage unrelated to images.

One thing I'm going to do is some archiving to cut down on "big" pages, particularly those that get loaded frequently.

Any other suggestions for cutting bandwidth, particularly in a mostly text-based environment?

[svseller]

Other compression solutions:

[xcompress.com...] (hardware device looks interesting

[redlinenetworks.com...]

These sites can tell you how much bandwidth you'd save on a given page (often 70-80% for text)

[GilbertZ]

Which forum software do you use. This may let people offer more specific suggestions.

[rogerd]

Gilbert, this site uses a framed version of Discusware. With a few tweaks, it performs well in search engines, and the visitors seem to like it. However, it is NOT a database driven forum - the pages are static html and a page is rewritten if a post is made.

Overall, it's a mixed bag - I really like the software and its reliability. It has been bulletproof since day one, and was relatively easy to tweak for better SE performance (topic-relevant titles and metas, restore frameset, etc.) However, as volume has grown it's showing some of the limitations of a static-page forum. It does have an auto-archive feature that could be used to cut down on page sizes, but my impression is that the structure isn't very visitor-friendly.

[GilbertZ]

I'm not too familiar with discus but from what I've seen they made a HUGE improvement of late.

When we started gzipping the data our bandwidth went down by more than half...

[Enigma]

I wouldn't remove alt attributres to reduce bandwidth. One should not compromise on accessibility and usability.

[g1smd]

I often browse the web from a PDA with GPRS connectivity. I turn images off to speed up downloads, and to reduce the phone bill as it is charged per MB transferred.

If there are no alt attributes on the Navigation buttons then the site is rendered impossible to use.

[Bangkok9]

Seindal is perfectly correct in "4:18 pm on Dec 8, 2002"

I would amplify a few points about using mod_expires in Apache:

If you are not the server admin, you won't be able to make this happen in the httpd.conf file. Instead ask your host to enable "Overide ALLOW" for your user directory, then you can use these directives in your .htaccess file.

Either of the techniques will eliminate many, MANY [ or MOST or ALL!] useless "304" hits to your server.

In Seindal's example, he uses "A" which stands for access -- the number of seconds that the resource [image,page,.js, etc.] can live in the client's cache before being rechecked with the server. Another option is "M", which counts seconds from the "Last-Modified" date on the server.

The contrast is that all "M's" expire at the same instant for all clients, whereas "A" is a client-specific expiration time.

If you have graphics that never [and WILL never] be changed, choose either option and set it to a few million seconds which is many years in the future. But remember that the only way to refresh that image will be to rename it on the server and in the HTML, providing for a new call to the server.

For some applications it's very useful to maintain two or more image directories each with a different expires setting in the .htaccess. Icons and widgets can be left on a long-expiry, while a banner that changes frequently [but where the filename does not!] should be in a directory with a very short or 0-seconds expires; the later has the effect of forcing a recheck/refresh every time a referencing page is loaded, even if the client has a buggy/gimpy caching mechanism.