Asymmetrical Information

First off, your header is huge. 17k, and it's physically large. I'd suggest (a) resizing it to something that doesn't take up as much space (b) use table backgrounds to fill in the background color instead of an image and (c) use the .GIF format. I tested it and I got your original header down to 3k in .GIF format. You can find it at http://www.robballen.com/images/AIblogtitle.gif.

This should cut down a little. Other than that, I don't see too many images on your site anyway. You could lower the number of articles shown on the home page. I know I probably suck up some bandwidth because I have your RSS feed constantly checked. I'll check less often to do my part.

Yeah, cut down to the last two or three articles posted; that would probably help a whole bunch (the HTML source, as downloaded, is 116K). Keeping the top three posts and nuking the rest brings that file size down to a somewhat more mangable 68K.

Another thing to try would be more judicious use of MT's extended entry feature...

Yeah, cut down to the last two or three articles posted; that would probably help a whole bunch (the HTML source, as downloaded, is 116K). Keeping the top three posts and nuking the rest brings that file size down to a somewhat more mangable 68K.

Another thing to try would be more judicious use of MT's extended entry feature...

I didn't check, so you might already do these things, but you need to make sure that:

1) Your server uses gzip compression (mod_gzip in Apache).

2) You probably have a lot of readers who check the RSS feed often. To do this without excessive bandwith consumption you need to support HTTP Conditional GET (ETags). This will prevent you from sending the data if the user has already fetched it.

3) Your RSS feed contains full text so people don't check through (a google search will show you how to make a full-text RSS template).

4) You should make your header graphic smaller. Use .gif.

5) You can keep fewer items on the homepage.

In addition to the fine ideas posted above, you might also consider adding a robots.txt file to your site to reduce some of the search engine indexing traffic.

If, for example, you've had plenty of search engines visit and index your site, you could add your older archives to the robots.txt file and reduce the number of times the spiders go riffling through the 2002 archives (for example).

Your RSS feed has items dating back to September. Every time someone's aggregator checks for updates, they may be getting the whole thing, even if they're only viewing the new items. You need to shorten your feed to the last 10-20 items - at the moment there's 250!

I think this is a problem with RSS not yet working quite the way it's supposed to. Eventually RSS should be able to save lots of bandwidth, but at the present I think it's causing problems - too many people checking too often for updates, and getting too much old data they shouldn't be looking at.

A full text feed might keep more people from clicking through, but if your ads are offsetting some hosting costs that may backfire...

Nathan, the RSS Feed only has the last 15 entries... The entries listed back to September that you see are probably due to your aggregator holding onto older entries from the past.

Robb -- thanks so much. Keeping in mind that I am basically a total idiot, how do I set up the table part?

Paul -- is there a way in MT to change the number of posts displayed? All I seem to have is a number of days.

Nathan -- how do I change this?

Lyn -- where, exactly, does a robots.txt file go?

Thank you all SO much for your suggestions. This is what happens when you get amateurs mucking around on the web, I supposed . . .

the robots.txt file goes into the root directory. It's a simple file - example follows:
User-agent: *
Disallow: /directoryName

where directoryName is the file or folder that you want robots to ignore.

Here's a tutorial or two:
http://www.searchengineworld.com/robots/robots_tutorial.htm
http://www.clockwatchers.com/robots_main.html

Well, with that gif that I did (only 3 k), you'd probably expend the same amount in text trying to get the table set up, so it's probably just as good to replace the current JPG with my image. If I get a chance tonight I'll see if I can code it quickly and compare to see if it's worth it. Other wise, you'll still get a 14k per view (assuming no cache) savings.

I don't know MT at all. I'm busy writing my own blogging software because, well, I'm a geek. However, you do need to check on your RSS feeds because they are huge.

Hmm...my post didn't appear to go through. Let me try this again.

I actually meant to say "or", not "and" so the table thing isn't that important, especially since the graphic I provided is a paltry 3k. You'd probably add 3k of text just trying to write the proper table code.

Just switching out that graphic should save you 14k a hit*.

Also, I agree with the RSS feed. It's huge.

*assuming the image hasn't been cached.

Hmm. I guess it did...

Find cheaper bandwidth? I've seen it as low as $0.75/GB. (Granted, for pricier dedicated hosting.)

Buy bandwidth in advance? Some places charge 2X for bandwidth in arrears.

The blogroll is 22.5 kB. About half that is titles of the form "Last updated: 10:52:45 [GMT-5] on Saturday, March 13". Does anybody use the titles?

Do you really need all the Archives links on the main page?

Several kilobytes goes for absolute links like "http://www.janegalt.net/blog/archives/2002_02.html" that could probably be done as relative links like "2002_02.html".

You could save a kilobyte by getting rid of newlines. ;-)

I'd suggest moving the blogroll to a separate page, possibly the links to the monthly archives, maybe even the little calendar and the Hot Topics links. Doing all this cuts the size of the front page in half.

Besides your banner image, that little Book Reviews by Jane Galt image is another 18KB! Crunch down that image, GIF would probably work.

I see some extraneous stuff in your style sheet, you can probably shave it down some. Just by eliminating the useless styling of the banner chops out about 400 bytes. I think you can move the style items having to do with trackbacks and comments to a separate style sheet. Ok, just tested it, this slims down your first page style sheet from 6K to 3K.

Also, make sure that the static files--the style sheet and the images--have long cache expiration dates (say, a week or a month).

I just switched to an aggregator (Bloglines), but am ignorant about how it works. Is there anything I can, should do to help? A setting I should change from defaults?

The commenter who mentioned mod_gzip was absolutely right. HTML-heavy pages can frequently be compressed by 80-90%.

Style sheets are also potentially a big winner as they are cacheable and will work for both your main page and your archives.

Your archives are not going to change, so providing the correct caching parameters via the Last-Modified, Expires and Pragma headers will help somewhat.

Try using PNG instead of GIF or JPEG for the title image. An 8-color PNG (which preserves the antialiasing) is only 2120 bytes, while a 2-color PNG is only 959 bytes. Examples at http://linux.danceslut.net/pictures/AItitle2.png and http://linux.danceslut.net/pictures/AItitle8.png

Other than that, the other commenters have pretty good ideas.

Try using PNG instead of GIF or JPEG for the title image. An 8-color PNG (which preserves the antialiasing) is only 2120 bytes, while a 2-color PNG is only 959 bytes. Examples at http://linux.danceslut.net/pictures/AItitle2.png and http://linux.danceslut.net/pictures/AItitle8.png

Other than that, the other commenters have pretty good ideas.

As somebody above mentioned, you should create a file called ".htaccess" (plain text) in the root directory of your site. This file should contain
the lines:
ExpiresActive on
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"

(and the same for .png if you use that format)
The effect should be that 99% of all requests for images from your site should go away, because a web cache between you and your reader should have the image cached. Right now such a cache is always checking if the image hasn't changed, sending an if-modified-since request. This uses much less bandwidth than sending the whole image, but that's still worse than almost no requests at all.

Gzipping the html of your main page would probably be the biggest bandwidth saver, but this comment is long enough as it is.

Ok, gzipping...
The simplest way is to add
the code described at:
http://www.scriptygoddess.com/archives/003627.php
to the very top of your page and rename
the main into .php (well, tell MT to do that, or tell Apache to treat index.html as index.php)
However, this will increase the load on the CPU
on the server quite a bit.
A better solution would be mod_gzip (if your hosting provider offers it) or something like jpcache.

Hmmm, I just noticed that Asparagirl's new page is gzipped, so maybe you could ask her how much extra load that is generating and how she's doing it?
Double hmmmm, your comments are gzipped, only your blog isn't...
If you can pinpoint the different settings, you could turn on gzipping for the main blog too.

Don't worry about the blogroll, it won't make a difference. Since you are using blogrolling, the traffic hit is on their server not yours.

Call me crazy, but fixing that strange comment posting delay would probably help quite a bit. I've lost track of how many double/triple comment posts that I see.

If not, maybe only letting a person leave a comment every 5 minutes would help

Not knowing anything at all about technology I can only offer a half-baked solution : stop writing so well that TCS links to a long article of yours.
( Perhaps of more use is www.sagonet.com. 750GB bandwidth plus dedicated server for $ 99 a month. No, not a salesman, just a user.)

I would also favor making use of the extended-entry drop-down feature. For example, when dropping by AI merely to check on the comments, especially under long posts like "conservatives in academia," I really didn't need to be loading the entire entry when I load the AI main page; I have already read it a couple times. Loading merely the first two paragraphs and a "Read more..." link would not only have been more efficient, for scrolling purposes it would have been more convenient.

Damn....your PNG is smaller than my GIF...

Well, at least someone who is still using Netscape 3.0 can see mine so nyah ;p

I don't know what you're paying for bandwidth or how much you are using but take a look at http://bloghosts.com/?page=plans

Thought I was going to be able to make some contribution to this but having read all the other comments I have realized that I am a completely clueless idiot. I would be grateful if you could Fed Ex me some of your contributors so that I can keep them in a cupboard for next time I get stuck!
Regards
Cass

One thing you may want to consider is changing hosting companies. My friend owns www.Ideas4Now.com and we can give you good hosting for $8.95 per month. If you put a small Ideas4Now link on your page I'm sure I can even get a larger allocation of bandwidth for you.

Check out www.HostMyWebsite.com or drop me a line at Brian@ideas4now.com if you are interested. I'll have to know how much bandwidth you are eating up.

How much bandwidth are you using, anyway? We appear to have comparable traffic and I'm only using 10-12 gigs a month--and my site tends to be more graphics intensive. HostingMatters--which isn't among the cheaper of the providers--only charges $11 a month for the account I use, less if you go annual (as I do).

Indeed, if you're paying more for bandwidth than you're generating with the BlogAds, something is seriously screwy. Your page isn't particularly large even as is by MT blog standards.

Yeah, cut down to the last two or three articles posted;

While this can cut down the size of the main page it may have the unintended consequence of more people loading your monthly archive page if they do not visit frequently.

And, what James J said 2 posts up. Surely, the dramatic increase in bandwidth costs you describe must be only a few dollars/month. Going to the next plan above james' gets you to 16 GB @ $16/month.

I have a very heavy page and was able to solve all of my bandwidth problems by switching to .PHP files instead of .HTML and running the GZIP functionality. Very simple to implement.

I switched from Hosting Matters to CSI and get 35 gigs of bandwidth as well as 1.5 gigs of storage for $30 / month. I consider it reasonable, but your mileage may vary.

You may want to consider hosting with Ideas4Now thru www.Host-Our-Website.com. $7.95 per month buys you 20GB per month. The Premium Plan is 60GB per month. I could work something out if you needed more transfer without the added expense...perhaps you'd consider adding a very small 'Ideas4Now.com' link on your page? It's always nice to have a somewhat famous client :)

Just drop me a line at Brian@ideas4now.com if you think this could help. We also have web site designers who can help you with some of the tweaks discussed here. If we had to, we can even bring in programmers to help out.

Please don't cut the number of posts on your main page. (Figure out some techy way to cut the size instead.) I suspect I'm not the only one who scans your site once or twice a week and likes to see as much as possible on one page without checking out the archives. Thanks.

Comments are Closed.