I try to operate this site in a way that gives you the best reading experience I can give you. To help meet this objective, I periodically run tests to see how well the site performs. In using Pingdom Tools to do that testing this morning, I found out that it was taking more than 8 seconds to load the front page of the blog. That is unacceptable to me, and probably to many of you. Also, my Google Webmaster Tools report is showing several “unreachable URLs,” and word from my server hosting company is that there are no server issues that would cause that.
In reviewing the results of the test, one of the things causing the long load time was an advertisement. It’s now gone. Another thing that caused some delay was that the site design was using several style sheets. This was not as large of a delay as one might think, but it was enough to cause me to at least temporarily switch to a different design. If I were using caching software, it might not be a problem at all, but caching software causes other issues.
I’m not thrilled with the layout of the current design (I prefer two columns instead of three), but it loads fast (about 3 seconds) and is very readable. So, I will use it for a while, and I may test some others, too. Ultimately I could return to the previous design, once it is modified to use only a couple of style sheets instead of several.
Anyway, I just wanted to explain the change to you. Many of you are totally unimpacted because you just read the articles in your feed reader. But for those who visit the site, I wanted you to know the scoop.
As always, I welcome, and need, your feedback.
Update for fellow bloggers:
I’ve decided to keep a running update here for other bloggers, just in case there is something that I find that can be useful to you.
One thing that concerned me was whether my WordPress database had become corrupted, thereby slowing down processing. So, I checked my WordPress tables against WordPress codex. I discovered that the Index values for my wp_posts table contained post_content instead of post_parent. It also contained some additional values related to a related-posts plugin I tried out a while back.
After a bit more research, I added post_parent as an Index item and deleted post_content, as it made no sense to me to have post_content as an index item. This seemed to give better performance, although I do not have quantitative data. (Note: of course I backed up my database before making this change.) I suspect that one of the related-posts plugins I tried made the change from post_parent indexing to post_content. Doing this did significantly improve the loading time of my WP Admin Panel.
Also, my wp_posts table contained some extra items, with one being related_posts … this item was adding an additional 2MB to my database size. I deleted it. I doubt that this makes a huge performance difference, as that item was not being used in queries, but it was taking up unnecessary space.
The lesson so far is to periodically check your WordPress tables to make sure they are not corrupted. This is especially useful if you have added plugins that might have made changes to the database (even if you have subsequently deactivated or uninstalled them).
The second thing I did was to eliminate the use of the Yahoo! Buzz social media button. Testing showed that it would sometimes take up to three seconds just to load the javascript for that button, which I doubt that anyone has ever used. So, I deleted it.
A third thing I tried was to move a couple of ad images to my Amazon S3 account, and server them from there. I had read that distributing http requests could improve performance. However, the ads actually served a couple of seconds slower via S3 than from my own server. Hence, I abandoned that approach.
At this point (February 25), the site loads in less than 3 seconds, consistently. However, I am just not happy with the Revolution Code Blue site design … it’s just “not me.” (For one, I wish it had more real estate for content and that it were more extensible.) But, I will leave it in place a while longer for continued testing.
Update 2 for fellow bloggers:
I have learned from my host that WordPress generally performs much better when the server has Fast CGI enabled, so I enabled it for my account on February 27, 2009. They also indicated that all WordPress blogs should use the plugin SuperCache in the Full-On mode (I have occasionally used the plugin, but only in the Half-On mode). So, I have enabled it in the Full-Mode and intend to keep it that way. Without it, WordPress simply can’t handle more than about 5 pages per second.
Finally, I am learning that linking to Amazon products can really slow the site loading down. Amazon has a 1 pixel image it appends to each affiliate link, and that image can sometimes take several seconds to load.