WordPress is one of the most popular CMS platforms in the world today. Many blogs ( including this one) and journalistic sites run on WordPress. WordPress works by dynamically pulling content from a MySQL database and presenting it to users in a theme.
This dynamic nature is one of WordPress’s greatest strength – as it separates the sites look from the dynamic elements driving the site. However it is also this greatest strength which can cause a popular site to struggle.
As more and more visitors come to a site, the server has to work more, establishing connections to the database for each page called, using up more server resources and generally slowing down the site for new users, thus becoming a problem.
A popular solution for this is the use of a caching plugin. Caching plugins work by creating a static (HTML) version of the page the first time it is called. By keeping this page available for future visitors you can, theoretically, reduce the load on the site. I say theoretically though, because in some load tests I ran last week, I saw that the caches may not work.
I am currently running a self hosted WordPress installation on a Media Temple Grid Server. I am running a light installation of WordPress with 5 plugins. One of these plugins is W3 Total Cache, which is one of the most popular plugins in the WordPress.org plugin repository.
Setting up the plugin however is not as simple as installing it from the WordPress repository. And it is here that I step back to question the necessity of the caching plugin. WordPress is known for its simple 2 minute install, this caching plugin had me spending almost an hour setting it up, and I still wasn’t sure it was done right.
The setup first involved me having to install a PHP caching extension to my server. This had to be compiled from source. Post which I setup the plugin, by reading through (thankfully) copious documentation provided by the plugin author. My first setup was woefully incorrect as it immediately started causing server errors on my site. My backup plugin started taking 15 minutes to zip a 100 mb directory.
Once I had corrected the issues and setup the caching plugin again, I did some tests using a service called Blitz.io. Surprisingly my results were better without the caching plugin activated than with.
Blitz tests called _rushes_ work by rushing a test site with a number of concurrent users over a set of seconds. I ran tests with a rush of 1000 users over 120 seconds.
Without the caching plugin active, I had an average response time (time taken to load first page) of 635 milliseconds, with a 21.37% timeout and a 1.7% error rate. This timeout number had me worried and I was hopeful the cache would run better. However my first run with the cache activated had my response time go up to 913 milliseconds with a 21.7% timeout and a 1.77% error rate. I reset some setting on the cache plugin and my response time went down to 827 milliseconds but my timeout rose to 27%, while error rate was consistent at 7%. The caching plugin was not able to reduce my timeouts and I also saw that the period the caching plugin was enabled, my host was using more resources.
In my view (at least in this current situation) caching should be a function of the hosting provider more than the CMS platform. Hosts like Media Temple, WPEngine and even WordPress.com dedicate a lot of effort to building caching into their products.
For non-technical bloggers who have chosen to have their blogs outside of WordPress.com for access to more themes and plugins, having the host take the responsibility and pain of handling caches is a better idea.
Considering the important nature that caching plays in a content driven site, it may also be considered that the certain basic caching features be built into the WordPress core. By building it into the core as a feature, it would also be easier for non-technically inclined users to use the feature.