I started by setting a group “instant unarchive” on the first two-hundred emails that I have. Then I did the select all action, and clicked the link that appears at the top of your email list when you select all to “select all 70 billion emails” and archived the bunch. I then clicked on the left the “instant unarchive” group, and moved them to my inbox. Ta-Da now I’m down to my latest 200 emails in my inbox. As some of these are still relevent & outstanding I’m going to have to archive them by hand.

The concept of having an empty inbox is pretty darned appealing to me. I’ll give you updates as I go. (oh by the way, the command key to archive an email is “e”)

How does keyword density in the title tag affect search engine placement? On Facts about Title Keyword Density, it says that Live.com rewards high keyword density in a title tag, whereas Google.com punishes high keyword density in a title tag.

I don’t really care about search engines other than Google. I’ve heard SEO experts claim that Yahoo! and MSN/Live still contribute a fair number of clicks, but that’s not true according to my server stats. I’d like to find out if Google really does punish keyword density in a title tag.

I created 3 similar pages for a fictional person, whose name currently return zero results in Google. Using the name as the search term, there are 3 different keyword weights.

1. Test A (100%)
2. Test B (50%)
3. Test C (9%)

This may not be the best test methodology, but at least it’s a start. In a few days, I’ll see how Google ranks them. Any opinions on how the pages will rank?

That might seem like nitpicking, but with over a million pageviews a day, all that ASCII can add up. Personally, I would prefer valid HTML, but I bet the financial side of that decision was pretty interesting.

I’d heard a rumor that, for similar reasons, Yahoo! used extremely short filenames for images, e.g. a.gif, b.gif, c.gif, etc. I don’t know if this was ever true, but it doesn’t appear to be now.

When I still relied heavily on transparent spacer GIFs, I put a 1×1 pixel transparent GIF at the server root (/1.gif) to achieve the shortest possible filename.

A few months ago, I noticed an interesting technique that Google uses to save bandwidth. Check out the logo image that they use on their search results page:

They can use the same background image several times on the same page by changing the background position via CSS. That means one image call for multiple images. One roundtrip from client to server, after which the image is cached and reused. The colors are similar between the images, so the file size is not substantially increased over the size of 3 separate images. This technique may not save Google a lot of bandwidth, but it speeds things up for the user and presumably reduces the load on Google’s servers.

Now I work on sites that don’t have a fraction of the traffic of a Google or even an MLive, and such bandwidth-saving techniques are largely unnecessary (from a costs standpoint) and ignored. But I still have a lot of respect for such clever ideas.

Now that more users are accessing the web from their phones, I think we could all stand to pay more attention to bandwidth again. I know that my phone cringes when it’s working on a 300K page (that in reality should be 30K). Maybe it’s time the 5K Contest was resurrected.