If you’re like me, and self host WordPress, this post outlines how to make your website as fast as possible.


The first way to make your site faster is by using NGINX. NGINX uses an asynchronous processing method, which means one thread can be used to serve thousands and thousands of visitors at once. It also uses very little RAM, in the range of a couple megabytes per thousand visitors.

Since NGINX can’t handle PHP without using an external process, you’ll need to choose between using NGINX with PHP-FPM and using NGINX as a reverse proxy to Apache. Using NGINX with PHP-FPM is easier to set up and maintain as you only need to deal with configuring NGINX for each new site, and not NGINX and Apache virtual hosts. Additionally, if using NGINX as a reverse proxy, you’ll need to have Apache listening on either a different port(typically what you’ll do if you only have one server) or different IP address. However, if you need support for .htaccess , you’ll need to translate all your rules over to NGINX, or use NGINX as a reverse proxy to Apache. Keep in mind that if static files are served with NGINX, and you’re using .htaccess to restrict access to files, NGINX may serve them without calling Apache, therefore bypassing those rules.

Personally, I use NGINX as a reverse proxy for Apache. The main reason for choosing this over NGINX and PHP-FPM is that VestaCP takes care of configuring all the virtual hosts for me. All I need to do to add a new site is enter the domain name, and everything is automatically done for me. Choosing this option means I don’t need to edit the NGINX config for compatibility with CMS’s, because I have full .htaccess support, and I also get a lot of the benefits of using NGINX(discussed later on).


Since NGINX uses very little RAM per visitor, it can take care of keepalives instead of Apache. This frees Apache processes as soon as the page finishes loading, while NGINX takes care of the rest. This allows for much more concurrency, as the time Apache has to wait for a free thread is significantly lower. The way to do this is simply by adding the following into Apache’s main configuration(probably /etc/apache2/apache2.conf):

KeepAlive Off

Caching, caching, caching

WordPress is fully dynamic by design, meaning each time a page is requested, PHP must be run and database queries must be made. While this won’t really affect low-traffic sites that don’t have much concurrency, once your site begins to grow, it’ll slow down. Caching resolves many of these problems by saving the results of one page load to use for the next.

Page caching

Page caching is likely the most important form of caching for your site. It caches the entire page on the first visit, and serves it to subsequent visitors. This greatly decreases the page generation time, as PHP doesn’t have to be run for each page load. This also gives the added benefit of your site continuing to somewhat work even in the event of a PHP or database failure. Upon updates to the content, such as a comment, most caching plugins will automatically clear the cache for you.

The easiest way to set up page caching is by installing a plugin. I recommend, and use, the W3 Total Cache plugin. It is by far the most full-featured caching plugin, and does a lot of the other performance features discussed later on in this post.


NGINX can also be used as a full page cache. If you’re using PHP-FPM, you can read NGINX’s tutorial on the fastcgi caching options. Otherwise, you can use the proxy_cache NGINX option, if you’re using Apache as the backend. Be sure to add and configure the proxy_cache_use_stale option. This tells NGINX to serve a stale version of the page requested if the backend is currently not working or returning an error. This way, Apache can crash entirely, and the most frequently accessed pages will likely be stored in NGINX’s cache.

Object caching

The biggest problem with page caching on WordPress is that it only works for users who are not logged on and did not leave a comment. If many visitors to your site are logged in, then page caching won’t increase your performance by much. So, the solution is to just cache parts of the page generation process, also known as object caching. Since object caching is just bits and pieces of the page instead of the whole thing, many cached objects will be valid for both users who aren’t logged in, and those that are.

W3 Total Cache can also do this for you. While you can use the Disk method, I don’t recommend it. Caching objects to the disk can actually _slow _your site down instead of speed it up in some situations. Since this is not always the case, it’s worth a try because it’s the easiest to set up, and will probably work if your server has a fast enough SSD. If all you’re after is simplicity, then see if the APC(Alternative PHP Cache) is installed. If not, you can install it on Ubuntu with:

sudo apt instal php-apcu

For optimal performance, I recommend you install Redis. To do this, simply run the following if you’re on Debian/Ubuntu:

sudo apt install redis-server
sudo apt install php-redis

Now, set W3 Total Cache to use Redis, and your site should be magically faster!


The PHP OPCache is an amazing little feature that can significantly improve the performance of all PHP sites.

PHP is an interpreted language. This means it’s basically compiled on each page load(not really, this is just the easiest way to explain). The OPCache stores the semi-compiled PHP bytecode in memory, decreasing the overall PHP execution time. If you’re using a page cache, this will have less of an effect as PHP isn’t being run on most visits anyways. But, if you’re not or can’t use a page cache, this will probably boost your performance a lot. All you need to do is add the following to your php.ini file:

<span class="s1">opcache.enable=1</span>


Decreasing the time it takes to generate page is good, and will increase performance. However, decreasing the size of the page also helps a lot. This can be accomplished in two ways: compression, and minification. Compression is most likely turned on by default on your webserver, and if not, W3 Total Cache will enable it for you, so there isn’t much to do in that regard. However, what you can do, is minify your page. Minifying your page essentially strips out all the fluff that browsers don’t actually need to render the page, such as spaces and newlines.

To enable this, simply enable the setting in W3 Total Cache. To do this, tick the box in the “General Settings” page, click something like “I understand the risks”, then finally, go to the “Minify” tab of the settings, and enable HTML, CSS, and JavaScript minification.

Leave anything I left out in the comments below!