WordPress is the most used content manager today and one of those reasons is to use technology available to everyone, mainly PHP and MySQL or any of its derivatives). But this makes the software dynamic as standard from the server.
But starting from the dynamics of PHP; we can also propose a series of cache layers that come as standard within WordPress itself, which can be extended with plugins or surpassed with systems.
WordPress has many options when it comes to cache layers. Browser, page, compiler, object, fragment, transient, database, or disk cache. The question is which of those should you activate?
Keep in mind that depending on each project you can activate or configure the caches in a more or less aggressive way, so before starting the first thing you have to do is test the different caches and verify that they work correctly according to your needs. After all, the cache is summarized in a verb: reuse.
One of the first cache layers to configure is the browser cache. Basically, what we are going to do is configure the web server for the most repetitive elements and that do not usually change in the same session are read once they are hosted in the user’s browser on their device and later, as the user navigates the web only has to load the parts that change but not the static ones. Usually, elements such as CSS, JS, TXT, images, videos are usually cached… come on, everything that does not usually vary very often. What is not normally cached is HTML, at least not here. With this we will get that the user has to make fewer calls to the server, reducing the consumption of bandwidth (the GB of the mobile).
A similar layer is the so-called CDN (Content Delivery Network) which is a cache layer between the user’s browser and the server. The main idea is twofold: on the one hand to make some static elements such as CSS, JS, images and others served from a place closer to the user according to their Internet connection, and on the other that the main server does not have to process less useful requests. In these cases, the data is stored in a distributed way and if you change something locally you must invalidate the content of the remote site.
So far, I have commented on the most static elements, but you can also cache some dynamic elements. In this case, I am talking about the page cache, which can be done in different ways. The key is that websites are not updated very frequently as a general rule, and although they are done very frequently, we could talk about 1 minute is a long time (the website of a digital newspaper, for example). If you have a lot of traffic, one minute is a lot of time and many visits. The idea is that as long as the site does not change, an already generated version of the page itself is served. WordPress has a series of hooks so that at the moment in which some actions occur such as publishing or modifying a content or comments are added, so that at the moment in which an editor makes changes to the content you can configure the system so that the next visit regenerates that page, and the users who come behind will already see the updated information.
Page caching can be performed primarily on two levels of systems. One of them would be to mount a proxy-cache layer. The idea is that a service external to WordPress will take over this cache. It is usually a software that acts as an intermediate point between the user and the web server and that stores a copy of the page. The system, through some rules, decides if it has the content and therefore serves it, or if it does not have it (or has to renew it) and asks WordPress to generate it and store a copy for the established time. The other option is that it is the WordPress itself through PHP that manages that cache layer; this case is usually the best known and is managed with the typical cache plugins.
Another layer is the one we find in the PHP source code. After all, how often does WordPress PHP code change? Even if we update all the plugins, translations, themes or the WordPress core itself, how many executions are there of that code that does not change? Well, there we have another cache layer, and in the case of PHP, it can be done with the Opcode cache system. The idea is that once the code is executed once, all the next PHP executions that are done the same and that will execute the same thing are minimally calculated so that the execution is faster.
The following cache layers primarily affect objects. The definition of object cache is unclear, but one of the biggest examples may be caching queries made to the database. After all, when you do an SQL query, unless a piece of content has changed, the information is usually always the same. This is why the results of those queries can be stored for more or less time (usually little). This way you can optimize, for example, the resources of the database so that it does not become saturated at times of traffic peaks. In this block, we can also include the cache of the Transient. This system basically allows you to change the place of storage of information from being in the MySQL database to move to a cache place that, in principle, will be much more optimal in terms of storage, read access and writing of information.
A little-used cache layer (as not all web servers allow it) is the fragment cache. The idea is very interesting and is based on the ESI (Edge Side Includes) standard. If you are one of those who program in PHP, surely you use the include() as a system to add elements that are always there. A very clear example of this type of cache is that of e-commerce stores. If we apply a page cache layer in one where there is a shopping cart, we have the option to create a different page for each of the users who have left something in the cart, even if the rest of the page is the same and the only thing that changes is the “number” that appears in the basket icon. This is absurd from the pure point of view, since you are storing maybe 20KB of something that is actually different from the other in 10B. The idea in this case is to have a copy of the page cache and that, only the fragment of the cart icon, has a cache according to each different user.
In WPSysAdmin there is more explanation about the different layers of WordPress cache. You also have available the download of the PDF of the WordCamp Sevilla in which I talk about the 10 cache layers.
About this document
This document is regulated by the EUPL v1.2 license, published in WP SysAdmin and created by Javier Casares. Please, if you use this content in your website, your presentation or any material you distribute, remember to mention this site or its author, and having to put the material you create under EUPL license.