This is a series of articles explaining how to speed up WordPress, the use of which is growing rapidly for CMS-based business sites and media sites. In the next few articles, I will offer techniques to tune WordPress’ speed by 1000x. --Kengyu Nakamura, Prime Strategy Co., Ltd.
In the previous article, we changed the web server to Nginx, and sped up WordPress 18.2x the default environment.
In this article, we are going to install the WordPress plugin WP SiteManager to enable page caching, and continue tuning to 228x.
This technique continues from previous tuning, so please refer to earlier articles to get to this point.
Enable page caching with WP SiteManager
This time we will be enabling page caching with the WordPress plugin WP SiteManager.
Page caching takes the HTML produced from the first access and temporarily reuses it in following accesses in order to speed up the display time. There are various types of page caching, such as those performed by WordPress plugins or those performed by middleware. For this column, we will be using the easy-to-use and multidevice enabled WP SiteManager.
Download and unzip WP SiteManager.
[root@ip ~]# cd /var/www/html/wp-content/plugins/ [root@ip plugins]# wget https://downloads.wordpress.org/plugin/wp-sitemanager.zip [root@ip plugins]# unzip wp-sitemanager.zip
Add a line to "/var/www/html/wp-config.php" and set WP_CACHE to true. This setting tells WordPress to use the page caching plugin.
(omitted)
define('WP_DEBUG', false);
define('WP_CACHE', true);
(omitted)
Next, go to the Dashboard and activate the WP SiteManager plugin. Now page caching is enabled. To check the settings, look for "WP SiteManager" in the left menu and click on "Cache".
Page caching will not be performed while you are logged in to WordPress. Log out to check the page load time. In my environment, the time was so fast that Firebug rendered it unmeasurable.
Return to the console to perform a benchmark test with ab. In order to prevent any inconsistencies, change the requests from 300 to 10000 and concurrent requests from 30 to 100.
[root@ip plugins]# ab -n 10000 -c 100 http://ec2-xxx.xxx.compute.amazonaws.com/
In my environment, requests per second was 2566.17.
| Tuning contents | Page load time | Requests per second |
| Default environment | 176ms | 11.24 |
| APC | 70ms (251%) | 29.20 |
| OPcache+APCu | 66ms (266%) | 30.51 |
| MariaDB settings | 64ms (275%) | 31.82 |
| Translation accelerator (cache) | 53ms (332%) | 39.29 |
| Translation accelerator (disabled) | 36ms (488%) | 56.78 |
| gzip | 35ms (502%) | ─ |
| Tuned settings | 34ms (517%) | 58.47 |
| event MPM+php-fpm | 33ms (537%) | 60.79 |
| AWS users | 31ms (567%) | 71.76 |
| PHP 5.6+OPCache+APCu | 32ms (550%) | 61.84 (550.2%) |
| PHP 7+OPCache+APCu | 18ms (977.7%) | 148.08 (1250.6%) |
| HHVM | 16ms (1100%) | 195.05 (1690.8%) |
| Nginx+PHP 7 | 16ms (1100%) | 151.07 (1344%) |
| Nginx+HHVM | 16ms (1100%) | 205.20 (1825.6%) |
| WP SiteManager | N/A | 2566.17 (22830%) |
With this tuning we have increased the speed 228x the default environment. And we managed to get 10x faster than just the Nginx+HHVM configuration.
Next time, we will go into the final stages of 1000x faster WordPress tuning by installing Nginx's FastCGI cache to get 1127x faster.
