WordPress Caching: Super or Total


This is a completely unscientific comparison of the two most popular WordPress Caching methods. In my case concerns involved not only speed, but also compatibility with existing plugins and themes.

Some background

I’ve been running this site on WordPress using various shared hosts for a few years now. For the most part the combination has served my modest means fairly well. This site gets on average about 80 hits a day with only occasional spikes (the record was a little over 20,000 hits one day due to a Digg. In addition I run numerous other WordPress sites none of which receive any real amount of traffic. As such my needs for optimization are more concerned with the limited CPU and memory available on the shared hosts I have been using as well as payload optimization to reduce the impact on slower user’s connections.

Given these modest performance requirements I also have 2 other requirements. First, any solution must be simple and require little maintenance. Two, any solution must not break what I have installed. Finally, I must be able to transfer the solution easily to other sites I run. This last requirement is based off the premise that consistency is a good thing when talking about back-end web development.

The Solutions

The first solution is WP Super Cache. This plugin was developed by WordPress core developers and is by far the most popular caching plugin available (as judged by the very scientific method of comparing the stats pages on the WordPress plugin pages). It is simple to use and effective at statically caching content. It’s weakness though lies in its simplicity. It is so simple that it does nothing to reduce payload and only statically caches dynamic pages to reduce server load.

The second solution is W3 Total Cache. This is a newer option by, apparently, a single developer. It does the same static page caching of WP Super Cache, but also adds numerous features such as minifying code, CDN support, database caching and more to both further reduce server load as well as payload. The problem here however is complexity. Configuration is far more in depth than WP Super Cache. In addition, the minify feature tends to break various themes and plugins (no matter of configuration ever allowed to get it working well with RocketThemes products).

Thoughts and Conclusion

As to which actually provides more complete optimization, well in theory, W3 Total Cache should win without even a fight. For my purposes however it still doesn’t fit the bill. I’ve found it to be simply too complex for small sites many of whom must be maintained by people who don’t even know the definition of caching. It can break sites on updates, cause numerous headaches, and in the end, without a lot of upkeep, doesn’t really do much to improve performance.

Needless to say then I use WP Super Cache on nearly all my sites. In addition I add to other plugins to help reduce bother server load and payload. First is DB Cache Reloaded which really helps reduce CPU load on shared servers by caching database queries. Next is WP-minify which combines and minifies all the javascript and CSS files linked to your site. Together not only does this combination visibly reduce loading times of my page, but they do so without a lot of configuration and without any unintended errors to my theme or plugins.

Installing mod_pagespeed On Individual Sites

Google’s mod_pagespeed is a great piece of software for speeding up web pages. Unfortunately however it doesn’t work for everything. Some of the most common filters can in fact cause your code not to validate at a minimum or, as a worst case, break your site altogether. For many of us who run our own servers installing mod_pagespeed may benefit one site while breaking another. Or, as in my case, different filters may be necessary depending on the site. Here’s a quick tutorial to make this work using Ubuntu Server 10.04LTS with named virtual hosts.

First, log into your server via SSH or otherwise.

Next we need to download the latest mod_pagespeed package.

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb

Note, that if you use the x86 version of Ubuntu server you’ll want to replace the above line with

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb

Next, install the package and clean up the installation file

sudo dpkg -i mod-pagespeed.deb
rm mod-pagespeed.deb

At this point mod_pagespeed will be installed, but we still need to configure it. We’ll start by editing the primary mod_pagespeed configuration file to disable the module globally.

sudo nano /etc/apache2/mods-available/pagespeed.conf

Within the file, on the 4th line it should read:

ModPagespeed off

Save and exit the file.

Next, we’re going to edit the individual virtualhost we want to apply mod_pagespeed to.

cd /etc/apache2/sites-available

Open the site you wish to edit in your favorite text editor and enter the following lines between the VirtualHost tags:

ModPagespeed on
ModPagespeedUrlPrefix “http://dev.aviation.siuc.edu"”
ModPagespeedFileCachePath “/var/mod_pagespeed/cache/”
ModPagespeedGeneratedFilePrefix “/var/mod_pagespeed/files/”
ModPagespeedRewriteLevel PassThrough
ModPagespeedEnableFilters add_head
ModPagespeedEnableFilters collapse_whitespace
ModPagespeedEnableFilters elide_attributes
ModPagespeedEnableFilters remove_comments
ModPagespeedEnableFilters rewrite_css
ModPagespeedEnableFilters rewrite_javascript
ModPagespeedEnableFilters move_css_to_head
ModPagespeedEnableFilters remove_quotes
ModPagespeedEnableFilters insert_img_dimensions
ModPagespeedEnableFilters rewrite_images
ModPagespeedEnableFilters outline_css,outline_javascript

note that you may wish to change the options. Click here for a list of available mod_pagespeed filters.

Save the file and restart apache.

sudo /etc/init.d/apache2 restart

Go to the site in question and view source (you might need to clean the cache out). You should be able to see the module in action by the changes to your page source.

When The Ax Man Cometh – An Excellent Piece on Higher Ed Live

Seth ODell at Higher Ed Live has another excellent episode this week this time focusing on the future of web professionals at higher ed institutions. This particular episode takes a look at where we are and where we are going including topics such as downsizing, outsourcing, and more.

As a higher ed web person myself I must say that I agree with almost everything Seth and his guest, Mark Greenfield from U. Buffalo, have to say. We are in for some rough times in an environment where higher ed has been under siege for the better part of the last decade. The latest recession is just the tip of the iceberg for many institutions which have come to rely on ever smaller staff and ever smaller budgets to present their primary face to the public. I personally don’t see things getting much better and in fact I would be surprised if half of us web folks in higher ed today are still in higher ed in 10 years. Even if I’m wrong however it’s still going to be a rough ride.

Anyway, check out the video for yourself:

Here’s a link to the original post at Higher Ed Live

Experiments with mod_pagespeed

I’ve spent most of the day working on optimizing my work sites with mod_pagespeed, a Google sponsored Apache extension that provides various features to speed up the loading of your website.

Installation was easy, just install the package from the mod_pagespeed website and enable it like any other Apache extension. The catch came in making it work with all the virtual hosts on my server. After installation 2 problems quickly arose. First, assets such as images were disappearing from our WordPress multi-site installation. Second, the CPU load on the server started to spike far above normal usage.

In the end, the best solution I found was to disable mod_pagespeed globally and enable it only on a per-site basis via the virtualhost configuration. Doing so has brought the CPU down to acceptable loads and visibly reduced the load time on our most important sites. Not bad for a free extension.

When I originally started this post I intended to make it a tutorial on enabling it and working with it in a similar situation. For now however I’m going to hold off until I can fine-tune my own installation a bit before I do so. In the meantime however things are looking promising, the question remains however whether it will actually live up to the promise.

PHP 5.3 – Finally Ready For Primetime

PHP Logo is nothing new. In fact, it was first released on June 30, 2009, almost a year and a half ago. Considering this is almost akin to going back to the middle ages in many other industries one would think that almost everything would be running PHP 5.3 right now, right? Then why has it been so slow in being adopted at so many places?

The simple answer, OSS CMS and other applications. Until very recently upgrading to 5.3 simply broke too many websites that relied on deprecated code to function.  For example, although Drupal Core was made 5.3 compliant with version 6.14 back in September 2009, many popular modules simply had not yet caught up. The same is true with WordPress where although 5.3 has been supported in the core installation for quite a while, many plugins and themes would quickly break when using the newer version.

These problems have plagued me at work for months. Particularly as we use Ubuntu servers which saw the default PHP installation upgraded to 5.3 back in April of 2010. We use MediaWiki, Drupal, WordPress, and other PHP software for our business and even with official support for PHP 5.3 in all of them our sites quickly became unusable in practice after upgrading. As a result we were forced to downgrade PHP to 5.2 in order to keep things working. While this solved the problem of our existing sites, it was far from an elegant solution and in fact has caused other issues resulting from a non-standard GD image library in Ubuntu’s PHP 5 packages prior to 5.3.

Fast forward 6 months later and it seems the last of our over 100 modules, plugins, extensions, and themes now function under PHP 5.3. The last roadblock was fixed for us in mid October and after 3 weeks of testing we were finally able to upgrade our servers to PHP 5.3 this last week.

For those of you in similar situation I would encourage you to revisit PHP 5.3 compatibility in your applications. The obstacles to it’s adoption seem to finally be a thing of the past and as it does offer some benefits over its predecessor it might finally be time to make the switch.