Corrected: Blogging Platforms, Simplicity, and Speed

Update: Based on information I received late this evening, I have made some corrections to this post. The short version is that (1) the Google Site Performance data appears to be grossly wrong, and (2) I would do well to continue with WordPress and with any of the themes I have used in the past (and at present). More detailed update information is weaved into the original article.

When I retired 3 years ago, I thought having a blog would be a nice hobby and that it would allow me to share some experience and learn from others. Since everyone seemed to be blogging, I assumed that it must not be technically challenging, so that I wouldn’t have to learn any new programming languages or become a design guru.

My assumptions were not particularly good, especially given that I like to tinker. And, if you are the kind of person who likes to tweak site designs and coding, then you have buckle down and learn a bit of PHP and CSS. Okay, no big deal … I like learning anyway. You can blog without tweaking, but it’s easy to get sucked into tweaking, too.

But I had also made a couple of implicit assumptions: that my blogging platform would remain stable and fast, and that the designs would remain easy to work with (and stable and fast). These were not good assumptions. WordPress, the blogging platform I currently use, has had numerous new features globbed onto it, and all of the extra coding has had an impact on performance. And new designs are now “theme frameworks” instead of themes, with built-in complexity that can impact performance. Update: The wording here implies that WordPress has become slow and that most of the framework themes are, too. That is a false implication. WordPress has more features than it used to, as do the new framework themes, and of course that has some impact on performance, but it is generally very small compared to other factors that impact performance (use of large images, several images, a lot of javascript, a lot of plugins that have their own javascript, and so on).

This site used to load into a browser in about 1 second. Now my tests indicate that it takes a minimum of about 4 seconds. So, I have been looking around for simpler themes, and have been finding that most of the new themes are “frameworks,” with lots of javascript and options, and that a performance test run on test sites for those “themes” often shows loading times in excess of 10 seconds. Theme Developers: if you have a theme that takes longer than 2 seconds to load, don’t expect me to even think about buying it. Fellow Bloggers: a couple of sites you can use to test performance (in addition to the Google tool mentioned below) are Pingdom Tools and WebPageTest (the latter is especially good … gives lots of information). Update: When I say that a page takes 4 seconds to load, it should be noted that the page is visible to the user in about a second, with all the text fully readable … some of the javascript and images are still be sorted through by the browser (for up to an additional 3 seconds), but the page is viewable in very short order.

I am particularly sensitive to this topic today because last night I ran Google’s new Site Performance tool, available in the Webmaster Tools area for my site, and found that my average page load time is an astounding 15 seconds (August through November):

From looking at the chart, it is clear that the average is so high because of a few outrageously large peaks. But, even the low values are in the ballpark of 5 seconds, which is just too much. Update: The Google chart is just grossly wrong … if my site performed that poorly, I could not even log on myself, and would have no readership at all. What could be happening is that Google is seeing all the mp3′s I have on this site (recordings of my fingerstyle guitar playing), and that is including downloading of them in the average. At a couple of MB each, that would add up to a lot, and give the skewed numbers. Another possibility is that Google is counting the time it takes to fetch the 1 pixel images that are tagged onto all Amazon Associate links, with a typical one being like
img src="http://www.assoc-amazon.com/e/ir?t=keenpda-20&l=as2&o=1&a=0143034545" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;"
My past testing with Pingdom Tools has shown that these images take a very long time to load (they may even be non-existent, and are just a coding trick used by Amazon). Since I have a lot of links to Amazon books, this could add up. However, I have doubts as to whether this is a factor: for one, I have another site (static html) that has several Amazon links, and its Google Site Performance chart shows load times of about 1 second, consistently. Regardless, the bottom line is that the Google chart is wrong, and sent me on a wild goose chase, although at least I got to learn from the chase.

So, I am currently looking for a simple, fast-loading theme, with a single stylesheet, and I am even thinking of switching blogging platforms. Thomas R. Hall is suggesting ExpressionEngine as an alternative to WordPress. In reading up on it so far, it looks like it is a great platform for smart people like Thomas. For old farts like me, it might have more of a learning curve than I want, and a lot of people do run WordPress on large sites (although often on servers that cost a few hundred dollars a month, instead of a couple hundred per year). But, I do expect to give ExpressionEngine a good evaluation. (I think the key difficulty is going to be in importing all of my existing posts into it.) Update: After doing more research overnight and getting some good calibration from some true experts at my hosting company, I am convinced that WordPress and my themes are just fine, particularly given that use caching and fast cgi. Hence, there is no need for me to go on a hunting trip trying to solve a problem that does not exist.

A final point: I do not want to come off as putting all the blame on WordPress or the available themes. The fact is, I have one ad image that is behind a secure socket layer (SSL) that is taking about a second to load, just for it. And, I use the ThickBox javascript for image enlargement, and it adds about a half-second. Then, I do not have gzip set in my .htaccess file, and that means I’m not shaving download time as much as I could. (My provider of my server discourage gzip use because using it puts more load on the shared CPU.) I also plan on implementing as many of Steve Souders’ performance improvement “tricks” as I can. (By the way, Steve’s blog runs on WordPress.) Update: In discussing this with my hosting company, they noted that is fine for me to use gzip, but that it will give very little improvement because most of the blog posts are relatively small, and that the very small improvement is generally not worth it (and does add a slight load to the server, although that is offset by caching and use of fast cgi.)

So, there are improvements I can make easily, without switching themes or blogging platforms. However, all factors do add up, and since Google will base site ratings partly on performance, it is important to have a fast site. (It’s always been important … just getting more so.) So, I will be doing some site surgery. But, YOU are the one that I think most about when I try to improve the site, so please let me know if any of my “surgery” is too drastic. Thank you.

Final Update: The Google Webmaster Tool forums are being used by some to report initial problems with the use of the the Site Performance tool. Many people are reporting that they have no issues at all, although there are some like me who are reporting on anomalous results. Google participates in the forums and is responsive to issues that are pointed out. I have no doubt that they will get the bugs worked out of the system. Frankly I am glad to see Google heading toward rating sites based, in part, on performance. Doing so should encourage better performance, which would be good for us all. (By the way, on 12.05.2009, the data showing for my site is now 3.7 seconds, having been updated through Dec 4th … recall that it started at 23 seconds. Apparently Google is analyzing the causes of the anomalies and making corrections, which is good to see.)