In this article you are going to learn the different types of caching that can be implemented to optimize WordPress performance and how they work. This is not a tutorial article per-se, but it will teach you a lot about all types of caching that can affect the performance of your site.
WordPress is a wonderful tool and is one of the most used in the world for making websites but it’s still based on PHP. So all the optimizations you normally do for any PHP script apply, so I am going to cover the different types of cache that affect WordPress performance.
The first thing you need to understand is that the deeper the cache level, the more effective the cache will be. The deeper level starts at the server, specifically the PHP interpreter, the next level is what is called OPCache which will cache OPCodes from PHP and comes as a module extension for PHP, then it comes the web server itself (can be nginx, apache or lighspeed for example), immediately after the web server you can also apply a FastCGI Cache inside NGINX or a Reverse Proxy and everything after that will come in the form of a WordPress plugin.
Caching can be implemented on some of the stages, all of the stages or none of them. The choice will always be yours and will depend on the load and type of project you have to work with. Some websites will require extreme caching mechanisms (all of this implemented) while others will do with just an OPCode Cache and HTML Static caching. It all depends on how light or heavy your WordPress project is. Having all of this caching levels does not mean you have to implement them all to get the best performance possible.
So, from top to bottom we have:
- PHP Interpreter: can be version 7, 5.6 or older.
- OPCode Cache: can be Zend OPCache built-in PHP or XCache for example.
- Web Server: can be nginx, apache or lightspeed for example.
- FastCGI Cache with NGINX
- Reverse Proxy: can be nginx or varnish.
- WordPress Caching: HTTP static content generation.
PHP Interpreter & OPCache
As a rule of thumb, the best caching possible will always depend on the latest PHP version, the newer you implement, the faster everything will be. For example, from previous PHP versions 5.4 to PHP 5.6 there is a performance increase because the interpreter itself plays a key role in how fast it compiles the code. Remember that PHP is just realtime code execution which means your server will have to do all the work. From version 5.6 to version 7 there are significant changes so you will always be better by using PHP 7.0 without some fancy cache than using PHP 5.6 with some form of cache. The interpreter version here is the key to obtaining a faster website.
Version 7 should always be preferred because its almost twice as fast as previous versions. It has the updated Zend Engine now called Next Generation. Since PHP 7 has the ability to execute code twice as fast and use fewer servers to do it, this in itself is as important as the cache you will implement.
With the PHP interpreter does come the new and improved Zend OPCache. What this level of cache will do is store the previous executed opcodes inside a temporal memory for later retrieval. Since the code you execute in your site will for sure run with similar OPCodes all the time, this will tremendously speed up code execution. And since OPCache is now an integral part of PHP 7, you don’t need to spend time configuring it.
The most important parameter in the OPCache is the memory used for storage. The more memory you assign to it, the more effective it will be; specially if the website is filled with plugins because, as a general rule, the more plugins you have, the more opcodes PHP will need to execute to make the website available to your visitors. OPCode cache can help you in bringing the TTFB (time to first byte) to a lower value since it will decrease the time the server has to take to process PHP code.
Web Server Caching
The web server is responsable for sending compiled code from PHP and static assets out of the server and into your browser, it’s a key part of the stack. All the major web servers implement a nice form of caching called static content and fastcgi caching.
When the web server needs to serve a request that does not need processing or is not dynamic in nature, it can be defined as a static content in the configuration. This can be applied to files like CSS, JS, JPG and PNG for example. This will speedup the site because static content is served much faster than normal content. NGINX is one of the ideal solutions to static content since it’s faster than Apache almost all the time.
By defining static content in the web server configuration you’re getting a speed bump to all the files that are not dynamic in nature, leaving the web server real work for the dynamic content, hence, improving performance.
FastCGI Cache with NGINX
You can also implement a fastcgi cache inside NGINX that will work very similar to a reverse proxy & http static content. This is a very good solution that could even remove the need to implement a static HTTP cache inside WordPress. What the FastCGI Cache inside NGINX will do is create a static output of all the contents already processed and send this into a temporal memory that can be either in the hard disk or memory of the server.
FastCGI Cache will generate an enormous amount of temporal files on your server but will also speed up the process tremendously, primary because it’s the same web server that will respond with a static image of your whole page when it is requested again.
This form of cache will remove the need to implement an HTTP caching plugin inside WordPress.
In the next level of caching there is the Reverse Proxy. This type of caching is very similar to FastCGI Cache with NGINX but it’s meant to be used when you’re planning on mixing web servers.
For example, Apache could provide dynamic content slightly faster than NGINX, but NGINX is very well known to provide static content much faster than Apache. In this situation you can implement a web server with Apache and put NGINX in front of Apache as a Reverse Proxy. This type of cache will work very similar to a static HTTP caching. The Reverse Proxy sits in front of the server and it’s the one responsable to giving you the final rendered page. It sits between the web server and the browser that will request the content. When the content passes through the web server for execution, the reverse proxy will store its contents into its own memory, so the next time the same page is requested it will just skip the web server php interpreter and provide the rendered page as it was stored.
A wonderful example of reverse proxy is Varnish, but NGINX is also really great in working as a Reverse Proxy.
Just remember that NGINX can’t work as web server & reverse proxy at the same time, for an NGINX only setup it’s much more recommended to just use NGINX with FastCGI Cache.
WordPress Caching aka HTTP Static Content
And now it comes the time where the actual cache is implemented inside WordPress. This is the easiest part. The vast majority of caching plugins for WordPress works by creating a static HTTP representation of the content inside the same file structure of the website. This way, when the next request for the same page comes, the plugin will just skip PHP by redirecting the web server to the HTML static content that was previously stored.
The most popular plugins known to do this are WP SuperCache, WP Fastest Cache, W3 Total Cache and others. The main drawback of this method is that it is constantly storing tons of static HTML files into the same directory structure of your website and this will count in case you are doing auto backups of your site.
The HTTP Static content cache is effective though, even if you fail to implement some form of cache on previous levels. This form alone, properly implemented, can accelerate your site tremendously because it will simply skip the need to use the PHP Interpreted to compile the code the next time it’s requested. The only situation in which you shouldn’t implement an HTTP Static caching on WordPress is when you enable FastCGI Cache with NGINX as that solution will not only be better and more effective, but will do the same thing the plugin is trying to do, only at a level higher.
You now know the primary levels where caching can be applied to improve WordPress performance. As you can see, the caching you do with plugins on WordPress is only the last step on the equation, which means your hosting provider will need to implement all of this on its own for you to reap the benefits. Sometimes this is not implemented because of compatibility reasons, and that’s why so many people choose to get a VPS plan and implement all of this on their own.