Skip to content

Posts tagged ‘wordpress’


How to Optimize WordPress, Part 2

My last post on how to optimize WordPress covered some general optimization techniques to speed up a website. Reducing HTTP requests, removing wasteful plugins and decreasing file sizes helped quite a bit. Now it’s time to try out page caching.

If you remember, the five things that normally occur for each page are:

  1. Initialize PHP
  2. Query the database
  3. Create the page
  4. Send the page
  5. Send additional files

Page caching plugins, like Hyper Cache and W3 Total Cache, eliminate steps two and three, except when creating a page the first time. WP Super Cache also cuts out step one.

All of the plugins were fairly easy to install. And I discovered during my tests that WP Super Cache, at least at Nearly Free Speech.NET, works just fine with safe mode on.

This graph shows the time it took to load my home page with each of the caching plugins enabled. I have circled the point where I first turned on page caching.

Graph showing response times with various caching plugs

Hyper Cache and WP Super Cache both performed well. W3 Total Cache seemed to struggle. It does more than page caching, like reformatting files to save space, but clearly slowed things down.

WP Super Cache has a few advantages over Hyper Cache:

  1. It supports browser caching better
  2. It doesn’t need to load PHP
  3. It checks for security problems and suggests fixes

So I am now a happy WP Super Cache user.

UPDATE Dec 2009:

After a few days, I started having issues with WP Super Cache and switched back to Hyper Cache. You can see how the irregularities went away. I’ve been using Hyper Cache for almost a week now, and things have remained stable.

Graph of WP Super Cache irregularities that were solved by changing back to Hyper Cache

After being contacted by the author of the W3 Total Cache plugin, I’ve agreed to give it another try. I turned off all the settings except for “disk enhanced” page caching. I’ll update the article again in a few days.

UPDATE Jan 2010:

After looking into things a bit more, my results are still showing Hyper Cache to be faster than W3 Total Cache. However, when I test using the curl command line tool from home, it seems that both plugins are about the same speed. My web hosting company uses a network-level reverse proxy and a few other caching tricks that eliminate the need for some of the features provided by these types of plugins. I’m not sure what’s going on here, but will be sticking with Hyper Cache for now since it appears to work better with my particular situation.

I do like that W3 Total Cache handles page compression properly. I could not get page compression to work with Hyper Cache and had to turn it off. I’d recommend you try all three plugins and measure which works best for you.

UPDATE Apr 2010:

I’ve been having some troubles with Hyper Cache recently. Page redirects were working properly in Firefox, but not in Safari. I tried a new caching plugin I hadn’t heard of before: Quick Cache. Redirects are now working in both browsers. After a week of using Quick Cache, it’s performance is very good. I’ve decided to stick with it.


How to Optimize WordPress

Having lived with WordPress for 8 months, I decided to see if I could improve the performance of my website. There are lots of things to fix.

For each page of my website, WordPress normally does the following:

  1. Initialize PHP, which is the programming language WordPress is written in.
  2. Read information out of the database.
  3. Translate the information into HTML.
  4. Send the HTML to the web browser.
  5. Send additional files needed to view the page.

One major cause of WordPress slowness is #2. Reading all that information can take several seconds per page. I installed a plugin called DB Cache Reloaded to help figure out what was going on. If you view the source of my home page, you’ll see something like the following:

<!– 1.549 seconds, 30 uncached queries, 0 cached queries, 10.76MB memory used –>

This tells me that there are 30 database queries just to show my home page. That’s a lot of slowness. You can also see how many seconds it took to generate the page, which is how long #2 plus #3 took.

The DB Cache Reloaded plugin works by remembering the result of each database query and, in the future, using the previous result instead of re-reading it from the database. With this turned on, about 2/3rds of the database queries are avoided.

<!– 1.236 seconds, 10 uncached queries, 20 cached queries, 10.76MB memory used –>

I also discovered that the KB Robots plugin makes a database query for every page on my site. Wasteful. Since my robots.txt file is simple, I removed the plugin and just created the file myself. One less query.

To speed up #3, I explored the idea of using a plugin to cache whole HTML pages. The most popular seem to be WP Super Cache, Hyper Cache and W3 Total Cache. Since none of them work WP Super Cache does not work when PHP is running in safe mode, I’m going to try them another time. But the performance improvement should be big because, these plugins allow me to skip #2 and #3. WP Super Cache will also skip #1.

Another point of improvement is reducing the number of things a browser has to download in order to show my site (#4). Most browsers will first download the page itself. Then if additional files are needed, such as pictures, style sheets or scripts, it will download them two at a time. When there are a lot of extra files, the overhead of downloading them can add up quickly. A caching plugin will not help out here.

Though I really liked my original WordPress theme, called Panorama, it uses a lot of extra files. They aren’t very big, but when downloaded two at a time they slow things down quite a bit.

Using a web page analyizer, I investigated how much work a browser has to do to download the files needed to display my website. The following table highlights the differences between my old theme and my new one, Titan, which uses about half the number of files (10 vs 22).

Panorama     Titan
HTML Images52
CSS Images82
CSS imports32
HTTP Requests2210
Size (KB)266240
DB Queries3032

Eliminating those small files (or combining several into one) makes a measurable difference. On the day I was testing, the average time to download my page dropped from four seconds down to two.

However, notice that the number of database queries is higher now. I believe this is because of all the options the Titan theme makes available. There were originally 35 queries, but Titan includes analytics, a box in the sidebar, and a category listing in the footer. So by using the theme options instead of separate plugins for each of those things, I was able to save 3 queries. And despite the small increase in database queries, my site still feels much faster.

One last thing I tried is removing some widgets from my sidebar. I put in a new archives section, using years instead of months, that I maintain manually. I will have to update it once each year, but it reduced the size of the page slightly and eliminated a database query. Lots of small and simple improvements can really add up.

Each of my remaining sidebar sections — Popular, Recent and Random — take about a fifth of the total time to create the page (#3). Taking them out would speed things up. But I like having them to help people find other articles to read they might find interesting.

The last point to mention is the plugin I use to find related posts. I really like having these suggestions for further reading. However, most of these types of plugins are really slow because they calculate “relatedness” each time a page is loaded. Wasteful.

I’ve found one that pre-calculates related pages every time an article is created or edited, but it is based on tags rather than the full article content. And I haven’t been tagging things. I tried some auto-tagging plugins, but could not find one that seemed to work well. So until I can get around to tagging all my articles, I’ll have to wait on that.

Overall, I am pleased with the results so far. I’m going back to tag my articles so that I can try out the new related posts plugin. Then I’m going to see about turning off PHP’s safe mode and turning on page caching.

UPDATE: I’ve written a Part 2 about my experience with caching plugins. You can read it here.


WordPress After 8 Months

Early this year, I switched from Movable Type to WordPress for my blog. I’ve been very happy with that decision. So I thought I’d give an update on how I feel after using WordPress for eight months.

First, I should say that the speed issue hasn’t bothered me like I thought it would. I haven’t added caching, but may still do so at some point. Let me know if things feel slow.

Second, I’ve changed the which plugins I use, so let me give you the current list.

  1. NEWTwitter Friendly Links let’s me use my own domain for short URLs instead of or
  2. NEWRF Twitter Post will update Twitter when I write a new post. I’m testing this one and hoping the next version adds support for Twitter Friendly Links
  3. NEWSexyBookmarks makes it easy for readers to share things they find interesting
  4. Aksimet filters comments from spammers of which there are many
  5. All in One Adsense and YPN handles the ads on my site though I have them turned off now
  6. FD Feedburner Plugin lets me use FeedBurner for my RSS feeds
  7. Google Analyticator adds the Google Analytics tracking code
  8. KB Robots.txt allows me to add my sitemap to my robots.txt file
  9. Markdown allows me to write using Markdown syntax
  10. Recently Popular highlights what posts people find interesting
  11. Simple Google Sitemap automatically creates a sitemap for me
  12. Twitter lets you know exactly what I’m up to at all times
  13. WP-DB-Backup makes it easy to back up the content on my site
  14. Yet Another Related Posts Plugin suggests additional posts that relate to the one you’re reading

Since January, I’ve stopped using Automatic Timezone because putting WordPress 2.8 and PHP 5 together makes the daylight savings time magic work.

Third, I was able to find several WordPress themes that I liked and get them installed fairly easily. And switching between them is simple.

Overall, I’m still very happy.

2009-12-05: I spent some time optimizing WordPress which you can read about here.


Movable Type vs WordPress

UPDATE: I’ve written a follow up after 8 months of use and two articles covering theme optimization and page caching.

About two years ago, I installed Mephisto and started blogging. I chose Mephisto mainly because it was written in Ruby, one of my favorite programming languages. However, I soon realized I was better off using the best tool for writing instead of caring so much about which language the tool was written in.

So I moved from Mephisto to Movable Type and was very happy with the switch. For a while anyway. Recently, there were several things about Movable Type that started to really bother me.

  1. Manual upgrades were annoying as they seemed to take a lot of time, and I occasionally broke things during the process.
  2. I never figured out how to install my own themes. My site looked bland for a long time while I waited for better default themes.
  3. I couldn’t figure out plugins either. I wanted to customize the sidebar of my site, so I ended up spending a lot time changing the theme by hand. After that, I couldn’t switch themes without losing all my work.
  4. Publishing static content just took too long. My site loaded quickly because of it, but I wanted something that wasn’t so annoying to me.
  5. I tried switching to dynamic publishing, but it didn’t work very well. It may have been my web hosting company, but I really like them and don’t want to switch.

My first thought was to try the hosted version of Movable Type over at TypePad. I’d never have to do an upgrade, and I assume the included themes are much nicer. However I decided that $9 a month is more than I wanted to pay to use my own domain.

Several of my friends and family use Blogger, which is free, so it seemed a good place to try next. Blogger only includes a few default themes, but adding your own is easy. It feels like thousands of custom themes are available, though I would have to install and maintain them myself.

Blogger does not support uploading PDF or MP3 files, which isn’t convenient, but I probably could have hosted them elsewhere without too much trouble. I also would have lost the ability to have a static page for our family newsletters. But the biggest issue was email. I couldn’t use my own domain unless I switched to Google Apps for email.

WordPress provides free hosted blogging accounts, so I thought I’d give it a shot next. I got quite far along the road to satisfaction. MP3 files were still evil, but PDF files were okay. $10 to use my own domain seemed reasonable. I found a theme I liked, and there was enough built-in functionality to get my sidebar set up how I wanted.

The biggest win was not worrying about upgrades or performance. WordPress would even import a blog exported by Movable Type. Awesome. Except I’d written everything in Markdown format, which wasn’t supported.

The WordPress guys said Markdown was more demanding on their systems, which sounded fair enough. So I had some fun writing a script to convert my Markdown-formatted blog entries to HTML. During the process, I found several broken links, which I was glad to fix.

But I found that writing HTML takes longer than writing Markdown. Not surprising really. It’s why John Gruber created it in the first place. Then I discovered that embedding YouTube videos required using some proprietary format. And then I realized they had the same email problem that haunted Blogger. I don’t want to switch to Google Apps. Please just add email forwarding as a paid upgrade.

I wasn’t happy. But after reading a bit more, I stumbled across the fact that the WordPress software could update itself. Interesting. I decided to try installing it myself.

Installing themes and plugins turned out to be fairly easy — unzip a theme into the themes directory, then select it on the Themes page; unzip a plugin into the plugins directory, then activate it on the Plugins page. Wash, rinse, repeat. Some of the plugins put their configuration pages into odd locations, but I was able to track everything down. And once I’d set up a widget in my sidebar, I could change themes without losing anything. It just worked.


Well, mostly. WordPress says it supports installing and updating plugins from within the software itself, which would be awesome, except that I couldn’t get that to work. Manual installation was easier. I sigh and shake my head whenever I think about it.

2009-01-21: I got automatic plugin installs to work by following these instructions (member’s only) on NearlyFreeSpeech’s forums:

  1. First I created a folder at the root of my site called “tmp” (for me, it was /home/public/tmp).
  2. Then I added this line to my WordPress configuration file: define('WP_TEMP_DIR', ABSPATH.'tmp');

The problem is that WordPress tries to download stuff to a temp folder before moving it to its final destination, but the system settings had the wrong temp folder listed. Since I’m running with PHP’s safe mode on, WordPress couldn’t read or write to the temp folder, causing the whole thing to fail.

It’d be nice if WordPress added a “Temp Folder Location” setting to their configuration options or just downloaded stuff directly to its destination if the temp folder is inaccessible.

I’m happier now that I can install, update and remove plugins, as well as update WordPress itself, all from within WordPress.

Here are the plugins I’m using right now.

  1. Automatic Timezone because WordPress is too lame to figure this out on its own.
  2. Google Analyticator adds the Google Analytics tracking code.
  3. Simple Google Sitemap automatically creates my sitemap.
  4. KB Robots.txt allows me to add my sitemap to my robots.txt file.
  5. Markdown (of course :-))
  6. Recently Popular highlights what people are reading on my site.
  7. Twitter lets you know exactly what I’m up to at all times. You do want to know this, right?
  8. Yet Another Related Posts Plugin works great and requires no work at all.
  9. Next of Kin isn’t activated yet, but I’m thinking about it.
  10. All in One Adsense and YPN handles the ads on my site.
  11. FD Feedburner Plugin lets me use FeedBurner for my feeds.

I tried these out, but stopped using them pretty quickly.

  1. Stats was annoying because it required me to login to my account every time, which didn’t work reliably. The reports and statistics were pretty good when I could get it to work.
  2. Redirection has a feature where it monitors post and category URL changes and automatically starts redirecting visitors. However, when I deleted a category, it created an endless redirection loop that took down my entire site. Other than that, it worked pretty well at helping me figure out and solve problems with missing pages.

More Good

I recently noticed two more things about WordPress that I really like.

  1. A word count is always visible when I’m writing. I’m happy the final version of this article is a few hundred words shorter than the original.
  2. My comments are automatically highlighted in a different color, which makes it easy for readers to find my replies. Not that you’d miss me in a list of three comments.

The Bad

There are a couple of things I don’t like about WordPress.

  1. Maybe I’m just used to Movable Type’s static publishing, but I’m not sure that’s a valid excuse for WordPress to be slow. Luckily, there are caching plugins that should help a lot. I find I prefer cached dynamic content over pre-published static pages. At first, it didn’t seem to matter, but one is handled for you behind the scenes while the other is constantly in your face. It may be a personal preference, but it makes a difference to me.
  2. The media library is pretty lousy. You can’t rename files, though you can delete and re-upload the file with a new name. I have to be extremely careful when uploading files.

Happy Ending

Overall, I’m very happy with WordPress. There is lots of good, very little bad, and no ugly. The hardest part was trying out similar plugins and picking the best ones to keep.