Skip to content

Posts tagged ‘caching’

9
Dec

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.

27
Nov

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
HTML11
HTML Images52
CSS Images82
Scripts53
CSS imports32
Frames00
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.