A brand-new installation of WordPress – with no pages, posts, images, or plugins installed – contains about 450,000 lines of code. Not all of the code must be executed every time someone visits your site, but a lot of it does. (Some parts repeatedly!) WordPress is using this code to build the page that your website visitor requested, and normally it will do it every time they visit, even if that page hasn’t changed.
Caching solves this type of problem. Caching tools create static copies of your site’s pages and deliver those instead if the page hasn’t changed since the user last visited. In other words, WordPress runs all its code and creates the page once, not every time.
If you’ve spent any significant amount of time reading about WordPress, you’ve likely encountered the term “caching” already. You’ve also likely seen ads telling you how much you need a caching plugin. These plugins do “page caching,” which means that they store static copies of your pages, as mentioned above.
Caching plugins are a good idea if you don’t have a better alternative. Bear in mind, any plugin that you add to your site adds to that 450,000 lines of code… meaning there’s more work for your website to do in order to get the page in front of the consumer.
The better solution is caching on the server side. Programs like Varnish can be installed on the server to handle caching for your site, eliminating the need for you to use a plugin.
In our discussion about webservers, we mentioned Apache2 and Nginx. Nginx has some great tools for page caching, and when you host your site with KMDE, Nginx page caching is part of our standard offering.
Because this is running on the server – and not your website – it is separated from the process of running WordPress and means that your site gets the benefit of page caching without having to put more load (and code!) on your site itself.
Other Kinds of Caching
There are other opportunities for caching besides just the pages on your site. One example of this is PHP’s OPcache.
PHP is an interpreted language, meaning that the human-readable code gets translated into something the computer understands (OPcode) as its running. This creates overhead while programs like WordPress are trying to deliver content to your site’s visitors. To offset this, OPcache can be configured on your webserver so that, when a given line of PHP is translated into OPcode, that translation gets stored (or cached) so that the same lines of PHP code aren’t being translated over and over.
There’s also object caching; this is often used for database queries. Remember that a CMS (Content Management System) like WordPress relies on a database (MySQL or MariaDB) to store information, and that information must be retrieved as part of the user’s request for a web page. An object cache – such as Redis – can be used to store query results in memory, making retrieval faster than getting the same information from the database every time.
So, do you need a caching plugin? If you site isn’t hosted with a vendor that provides something for page caching – and if your site is responding slowly – then yes, you might want to investigate caching plugins. Of course (shameless plug alert!) we use all the above caching models for KMDE WordPress sites, so you’re welcome to contact us to see what we can do for you.
Hopefully this post has been a helpful overview of the concepts around caching as it relates to your website. If you have questions, corrections, or comments, please feel free to add them below.