Dan and Cheryl’s Place

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	1	1
HTML Images	5	2
CSS Images	8	2
Scripts	5	3
CSS imports	3	2
Frames	0	0
HTTP Requests	22	10
Size (KB)	266	240
DB Queries	30	32

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.