This is a targeted exercise, and you are correct that there are larger issues at work on both the client and server sides of the Interwebs equation. Jason's tips are meant to provide the little guys, like me, with a way to accomplish two things: 1) serve pages faster and 2) save on server load, which also (bonus) lightens the overall consumption of energy.

I say little guys because I can't control what iron the data center uses, what CPU is in that iron, how the CPU handles I/O and idle times, etc. I also can't control the overall load, just my own little piece.

So, if your point is that this is a little thing, spot on.

Suppose the server is not serving the pages anymore, “saving the environment”. Isn't it still up and running? Only instead of being busy, it is doing idle loops. BTW, there is an opinion that the current data centres aren't loaded even 10% of their capacity, and the problem is not the lack of the job to do, it is the lack of progress on all of the fronts, meaning IO wait and idle loops waiting to sync up with the other components of the distributed system. (See AMD's guy talk on TheRegister)

Let's take the efficiency into account, i.e. how many Watts were spent on a single CPU cycle doing useful job. You can reduce the amount of job to do (rewrite the code to reduce the complexity of the problem), you can reduce the number of the wasted CPU cycles (rewrite the code to optimise synchronisation), and not only reducing the Watts spent by a single CPU. Otherwise, perhaps, 80386 would be the better option than Opterons and Xeons, because 80386 spends so much less energy per hour!..

Just my 2p, which under current market conditions are the same as your 3.9 cent.

Seriously, though, I think this makes a lot of sense and someday in my copious free time, I'll see about raising my score too. Thanks to you (and Jason) for bringing this to everyone's attention–good stuff.