WordPress Responsiveness, Part 2

In Wordpress Responsiveness Part 1 I introduced you to the basic concepts behind one aspect of your website’s performance: how fast it responds. In part two I will go into more details of using WP Super Cache to improve your site’s speed and responsiveness.

Caching, What It Is And Why It Matters

When you load a Wordpress site in a browser the server is consulting one or more databases and generating the page dynamically. This is rather like ordering food in a restaurant which makes it after you order it instead of grabbing it from a warmer. As you can imagine this can be a slow process as the web server often talks to another server where the database lives and then has to wait for the database to reply with the data. Once the web server has the data it then needs to turn that into the HTML which the browser then translates into what you see.

In many cases, however, the page doesn’t really change that much if at all between users. For example, when you load up the front page to this site it will look just like the person before you and the person after you, unless I publish a new article. Caching the page eliminates the time to build by essentially saving a copy and using it until something changes. This is where WP Super Cache (WPSC) comes in.

For most sites, the default settings for WPSC are good enough to see a nice boost in performance. The busier your site, the better the results. However, if your site isn’t under a near-constant flow of traffic you can see little to no benefit. This is due to WPSC only keeping a given page cache for a short time to ensure freshness. It tries to strike a balance between stale content and rebuilding the page too often.

Cache Expiration

On the Advanced tab in the WPSC settings panel, scroll down until you see the bolded heading “Expiry Time & Garbage Collection”. Here is where you can tune the expiration of pages to meet your traffic flow.

Note: If you are using preload mode, these settings will be ignored.

First, lets deal with the rarely changing site. If you make changes to your site only once per month, you shouldn’t be rebuilding the cache or expiring it more often than say every 3-4 weeks. To do that you could add up the number of seconds in 3 weeks and enter that in the first box, “Cache timeout”. You also will need to configure how often WPSC checks for expired pages. Here again you will need to configure it to something in accordance with your update frequency. To clarify, the first item controls how old a page can be, and the second controls how often pages are checked for expiration.

This combination provides a means to keep your site fresh but still responsive. For example, if you have an expiration of 600 seconds (10 minutes) and schedule the check for midnight every day, you will expire any page that has been cached for ten minutes or longer at midnight - even if no changes were made.

Thusly if your site doesn’t change more than once per week and you set 600 or even 3600 seconds for the cache timeout and check at midnight, you will be expiring every page you didn’t change that evening. This would mean the caching is giving you next to no benefit as each page would need to be rebuilt when the next user hits it after midnight.

If you post an entry every day, you might consider an expiration of perhaps a week but check for expiration every day. This would mean changes are caught each day but each cache page will be fresh for a week. It really is up to your traffic patterns as to how long you keep pages in the cache.

Knowing this, you can imagine how much caching matters for busy sites. However, what many fail to grasp is it can be even more useful for low traffic sites. To do this, you can use WPSC’s “Preload Mode”.

Preloading Cache

Preloading the cache is pretty much what it sounds like: WPSC can generate the page and store it before a reader ever sees it. This makes your site respond quite quickly. However, it has a down side.

By generating them ahead of time, pages can be out of date when viewed. For example, take the tag cloud on the right side of this page. That section of the page is normally generated dynamically on every page load. This means a DB hit and all the work mentioned earlier.

With preload mode each page is fully generated and stored. So what happens if I add a new article with a new tag? The tag cloud will not change except on the front page and the article’s page itself. Worse yet, if you preload the tag pages the new article won’t appear on it.

So how do we address that, and how to we use preload properly?

The settings on this tab are deceptively and thankfully simpler than the advanced tab. First I’ll discuss the checkbox options, then the number field.

By enabling preload mode (the first checkbox), legacy cached pages (i.e. not WPSC cached pages) will not be cleaned up automatically. This is generally fine so leave it or turn it on.

The next decision is whether to preload your taxonomies. This means the tag cloud to the right and if used archive indices and category pages. This is where it gets interesting. I recommend enabling it as it comes into play when someone has reached an article on your site and is looking to see what else you wrote. If this process is slow, she will move on and you lose a chance at more readers.

The final options are about getting status emails when the cache is preloaded. I recommend enabling this for the first few weeks or months to get a feel for how well the preloading is working. This brings us to the full rebuild interval option.

This option determines how frequently your site rebuilds the entire cache. This will catch any and all changes ade in the intervening window. This setting should be set to approximately your change frequency. If you make changes once a month, don’t set it to daily or hourly. The more pages you have to be generated the longer the process takes and the more resource hungry your site is. If it takes 5 seconds to generate each page and you need to generate 100 pages, that is a long time to spend processing pages.

In addition to the automatic refresh, you can set a long refresh time and remember to hit the preload now button after each set of changes are complete. However, this runs the risk of stale content if you forget or if you schedule posts for later publishing.

Summary Part Two

As you might imagine, I make heavy use of WPSC and preloading on this site. I dont make changes very often and do not (yet?) have significant daily traffic. As a result I tinkered a while until  I found the settings which enable me to keep the entire site cached for long enough to still be of use but also be fresh enough.

In Part Three I’ll dive into how to use a Content Delivery Network (CDN) in concert with WP Super Cache to provide even better performance. In the meantime start looking at your traffic profile to find the settings which work for your site; be a better neighbor and information provider.