If you haven’t read my previous article covering WordPress 4.0, please read it first. As it covers my testing methodology and test platform, it won’t be detailed again for this article. Now that WordPress 4.1 has been released, we've re-run the testing to compare the results and see if there are any performance gains.
For the 4.1 testing, I rebuilt the VM (using the exact specs) and ensured it was running on the exact underlying system specs. This is to ensure as much consistency as possible and to ensure there’s no hangovers from the previous testing.
So, lets start out with our base benchmark, using PHP 5.3 and MySQL 5.1 since we're using a clean CentOS 6 server. Again we’re simply using Apache Benchmark with one concurrent connection and 50 requests to the default homepage. This just to give a very basic view of how it works and isn't designed to be a comprehensive look.
Here’s our first result:
Requests per second: 3.93 [#/sec] (mean) Time per request: 265.145 [ms] (mean)
Now lets compare. WordPress 4.0 had an average time per request of 305ms. WordPress 4.1 has an average response of 265ms. While there's certainly an improvement, it's not a night and day gain. And, this isn't to be expected. Seeking performance gains and optimisation of codebases as large and complex as WordPress is far from a trivial task.
As one of the changes with 4.1 was a new theme (Twenty Fifteen), I thought it’d be pertinent to drop it back to the Twenty Fourteen theme so ensure the performance difference wasn’t theme based. The results:
Requests per second: 3.72 [#/sec] (mean) Time per request: 271.144 [ms] (mean)
So, we’re seeing roughly the same performance. Of course, with just the default homepage this isn’t highly taxing on the templating system but it’s good to know that a clean theme doesn’t affect performance.
As per the last testing, lets add some plugins. Like last time, I’ve added some of the most common plugins customers use. Since we covered most of this in the last test, I’m simply going to display this as a table:
|Contact Form 7||371ms|
Again I want to make it abundantly clear, adding plugins isn’t a bad thing. It should simply be noted that the more functionality you add to your site, the more you need to consider the performance. This time around, we can see that the performance difference of adding the plugins stayed mostly consistent.
The only exception was wooCommerce. This could be due to the newer version used (2.2.11) or indeed changes within WordPress 4.1. Either way, seeing performance improvements is always welcome.
Now we go through the latest PHP versions to see what differences this makes with WordPress 4.1:
|PHP Version||Response Time|
The performance does increase slightly with the new versions, but not enough to be statistically significant. The variances are within 2%, which could simply be a margin of error within our test environment. Conversely, it does show that upgrading your PHP version won’t hurt your performance either.
Now for the two tests which contributed significantly last time. The first is the PHP OPcache. This results in a response time of 121ms. Wow. Like WordPress 4.0, utilising the Opcache makes a significant difference and with WordPress 4.1 even more so.
And then we enable our favourite, W3 Total Cache. As per our install guide, we simply enable the page cache and browser cache for the most compatible and easiest gains in performance. This drops the response time down to 0.95ms. In fact, with the single connection this allowed Apache Benchmark to make over 500 requests per second. With multiple concurrent connections, this could easily be five times this without any real effort or specific tuning.
Here's a quick side-by-side comparison of the results:
As the data shows, there are some small but notable performance increases from running WordPress 4.1 under some scenarios. Especially if you have large or complex plugins like wooCommerce, running the latest version can make a difference. Overall though, if you’re chasing performance gains then you should be implementing Opcache and full page caching (via W3 Total Cache).
The other important thing to note is the importance of keeping your WordPress site up-to-date. Even if there were slight performance losses, ensuring your site is kept up to date is outweighs this in terms of risk. It also needs to be stressed that this includes themes and plugins, which is where the security vulnerabilities normally lie. You also get the benefit of all the new features included as well, so ensuring you update to the latest WordPress upon each release is a no-brainer.