Also of note is that Transients are inherently sped up by caching plugins, where normal options are not. A memcached plugin, for example, would make WordPress store transient values in fast memory instead of in the database. For this reason, transients should be used to store any data that is expected to expire, or which can expire at any time.

It’s simple enough to use the API. You just call the set_transient(), get_transient() and delete_transient() functions where appropriate. You can read up on the usage over at WP Engineer or the WordPress Codex.

Fortunately, there is a way around it in some cases. If you have a function in your template, you can do something like this:

<!--mfunc function_name( 'parameter', 'another_parameter' ) -->
 <?php function_name( 'parameter', 'another_parameter' ) ?>
 <!--/mfunc-->

You take a function call and surround it by the “mfunc” comments, in which the first contains a duplicate of the function. This will (somehow) instruct WP Super Cache to allow the function to execute, even in the static cached version of the page.

But what if you’re running on your own server, be it VPS, dedicated, or something else along those lines? What can you do to squeeze some extra performance out of your high-traffic blog?

Enter W3 Total Cache, a plugin that the infamously slow-loading blog Noupe has recently started using to combat the sluggishness that their constant social media hits cause. It can do a lot of things, including:

• Offloading static content to a CDN, if you have one.
• Minifying and compressing your CSS and JavaScript files, and caching them in memory or disk.
• Caching RSS in memory or disk.
• Ensuring that browsers cache things, such as images, CSS and JavaScript on their end for future page loads.
• Caching database objects in memory.

The plugin’s biggest feature is probably its support of various memory caching systems, such as memcached, APC, and XCache to store things in memory. This makes things very fast. Hard disks are a major bottleneck in servers. If you put frequently requested information in RAM, it can be served a lot faster. Try visiting a page on Noupe. It may load a little slow the first time if the page hadn’t been viewed recently, so you may have to load it again a second time. Things are real fast once they’re in the RAM cache.

I’m thinking of trying it out for myself in the future, once I go through with my plans to move from Apache to NGINX server software, which should free-up a bit of my RAM.

Note that these require that your server have certain modules installed for this to work. You will need either mod_deflate or mod_gzip for GZIP compression and mod_expires for the browser caching trick.

Enable Browser Caching

When a web browser loads a page, it checks each item it requests (JavaScript, CSS, images, etc) against its local cache. If an item, say the stylesheet, hasn’t expired yet, then it will load the local copy instead of requesting a new one. Now if you were to instruct your server to set the expiration time for images, CSS, and JavaScript files to one month from the present, users viewing multiple pages of your site (even across multiple days) won’t tax your resources as much, as they will use the copies of your stylesheets and images that have already been downloaded.

Insert this into your .htaccess file or Apache config, restarting Apache if you chose the latter:

<FilesMatch "\.(ico|flv|jpe?g|png|gif|js|css|swf)$">
 ExpiresActive On
 ExpiresDefault "access plus 1 month"
</FilesMatch>

Now any file with an extension of ICO, JPG, JPEG, PNG, GIF, JS, CSS, SWF will be set to expire one month from the time the browser caches it.

GZIP Compression

Now wouldn’t it be nice if you could cut down on the size of the file? There’s no point in doing it for images (which are already compressed) but you can greatly reduce the size of text-based files (HTML, JavaScript, CSS) by having the server compress them before sending them out.

Add this to your .htaccess or Apache config (restarting Apache if you chose the latter) as before:

SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ \
 no-gzip dont-vary
SetEnvIfNoCase Request_URI \
 \.(?:exe|t?gz|zip|bz2|sit|rar)$ \
 no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

This beast does several things. The first directive tells mod_deflate to get to work. The next several lines determine how mod_deflate will work. It will not affect GIF, JPG, PNG images or already-compressed archive files (e.g. ZIP or RAR), as there is no real benefit in doing so. The final three “BrowserMatch” lines deal with Internet Explorer’s funkiness.

Is it Working?

If you have Firebug and the handy Google Page Speed extension installed, you can run a quick test to make sure everything is working right. There should be two lines mentioning “Leverage browser caching” and “Enable gzip compression.” They should be checked-off instead of having a red icon.

If a script’s output doesn’t change every time a page is loaded, does it need to be processed each time? Probably not. You can cache a page, or a section of a page, for an appropriate amount of time, and serve it up instead.

It’s a lot simpler to implement caching than you would think. It’s just a matter of using output buffering, a little bit of basic file I/O, and watching the server’s timestamp.

PaperMashup.com has a short article on how to apply a basic cache to your scripts.

It’s not a good idea to go away and cache your entire site, you need to think about which pages receive high traffic, and which pages make a number of database requests. Static HTML pages aren’t going to see a benefit from caching and may in fact be served slower due to PHP invoking the request to the cached version.

It’s a great idea, but I’m not about to install it yet. As it says on the website, “dynamic content such as that within the sidebar, will only refresh when the cached pages are refreshed.” That, of course will cause major problems with some plugins. It’s hard to explain why those plugins won’t work, but I can give you some examples.

• Popularity Contest
• Landing Sites

Basically plugins that need to run PHP routines on every pageload. Plugins like Share This would work fine, because they always output the same HTML. Popularity Contest is a great plugin that is widely used across the blogosphere, but I can’t imagine it being possible for it to work with WP Super Cache.

Interestingly, Holy Shmoly (where the WP Super Cache download is located) is running the caching plugin…yet there is a “popular posts” list in the sidebar. Does Popularity Contest somehow work with WP Super Cache…or is the list just a static part of the template? I don’t see how Popularity Contest could work with Super Cache, as it counts the number of post views as they happen. The original WP-Cache 2 had a feature to make part of a page dynamic… Does Super Cache have that ability as well?

On the up side, WP Super Cache makes your blog wicked fast. In the past few days, there were a few blogs using the caching plugin on the Digg front page. They stayed up, and ran reasonably fast. Now that the worst part of the Digg Effect is over, they run a lot faster than a normal WP installation.

I like the idea of caching this blog, but I’m not about to do it unless I can keep Popularity Contest.