wordpress caching

Why is caching so important ?

The caching of a WordPress blog is probably the most important aspect of a successful Performance Optimization. Without caching there is virtually no real scalability, without caching high visitor numbers are hardly conceivable. WordPress eats up a lot of resources and is completely dynamic, which basically means that each page is created completely new from the individual parts with each call. For every user, of course.

WordPress then combines the individual components of your blog to a large whole and generates the finished HTML page. The sidebar is assembled together with the widgets, the article layout with the actual content is retrieved from the database and the theme builds the actual blog or blog post from it.

Quite a lot of effort for a single page view, especially if you consider that there are several of them in a row or even at the same time, after all you have more than a handful of visitors and so the server is quickly bombarded with hundreds of requests.

Dynamics has its problems in live operation, but caching is there to compensate for them. Fortunately WordPress makes things easy.

The country needs more statics

In general, the problem with WordPress is that dynamics does not really help us. No question, dynamism used to be a big thing, but in times when I call up a website on my smartphone and then immediately get the hint that my tariff has been throttled due to too high data transfers, dynamism somehow seems out of place.

Statics is in trend, caching in every area, as well as performance optimization to the absolute limit. Above all, however, minimalism, because if you transfer a lot of data, you also cause high loading times and if you rely on dynamics, you also cause a lot of server load. So they say: Less dynamics, more statics!

By using caching, the dynamic page structure of WordPress can be massively accelerated. The browser contacts the server, which in turn calls up the PHP files. Via PHP the core of WordPress is started, which loads the necessary information from the database. This information goes back to the core and the compiler creates the finished HTML page of the blog. This is sent back to the browser.

WordPress Caching in detail

When we talk about WordPress Caching, we are not talking about an either/or, but we are talking about four fundamentally different types of caching. What exactly this means and which areas we are actually talking about, I have taken apart for you and hopefully summarized it in a simple and understandable way.

This is not always so easy with technical topics, but I think I still managed to reduce the basics to a clear description.

Page Caching: The simplest form of caching. Here the dynamically generated pages of WordPress are simply stored as static HTML copies on the server hard disk or in RAM (Memory Cache). Instead of generating a new page each time, from now on the already generated copies are delivered. This is fast and relieves the server, and it also bypasses the page generation.

Database Caching: The database is the heart of WordPress, because this is where the actual content is located. Unfortunately, databases are extremely resource-hungry and often the bottleneck (i.e. the weak spot) of hosters. For each request, the same data is sent back and forth over and over again. One of them asks for, the data is sent.

The next one requests, again exactly the same data is sent. This is inefficient. Such cache queries are called database caching. Instead of sending the same query again and again, it is simply cached together with the result of the respective query. With a database-intensive CMS like WordPress, this is extremely important.

Object Caching: WordPress itself already has various caching systems, for example the Transient APIor even the object cache. In general, these systems are used to cache WordPress plug-ins in order to cache data and thus work much more efficiently. Then complicated requests can be easily cached, because the re-generation would be too complex or cumbersome.

Opcode caching: Opcode caching is similar to database caching. But instead of caching database queries, it is about PHP code. Basically WordPress is based on many small PHP commands, as can be seen in the theme and the individual files. These commands are now processed one after the other by the PHP compiler and converted into executable code for the web server. Opcode Caching now takes care of the code that comes out of the PHP compiler, so it saves the finished result.

HDD or RAM Caching?

When it comes to caching, the user usually has the choice between the hard disk (HDD) of his own server, or RAM. When it comes to cache performance, of course it depends on the respective hardware. How is the hard disk connected, is it an SSD or High Performance Hard Disk and so on. Basically it can be said that RAM is actually always faster.

But memory is always more expensive in server configuration and it may be needed for many other things on the server. If it is now responsible for caching, the capacity may be lacking elsewhere. So it requires a healthy amount of background knowledge and experience to use it in a meaningful way.

With WordPress, the so-called hard disk caching, i.e. caching on the hard disk (HDD) has therefore proven to be particularly valuable and efficient. For most people this is cheaper and often simply more effective, especially since share hosters or V-servers often don't give you the choice and therefore only the HDD for the cache is available.

So RAM caching is ultimately more for experienced users, while the normal blogger would rather use the hard drive to store the cache. This usually works safely and without problems.

WordPress Caching Plugins

For WordPress Blogger, the first step in the optimization process is always to install a suitable caching plugin. With WordPress, caching plugins ensure that the system no longer generates the pages dynamically, but stores them statically in a cache folder.

Instead of generating the page anew from the individual components each time it is called up, as explained above, the finished result is saved as a simple HTML page. This page is now in the cache folder and instead of generating the page anew for each user, a WordPress caching plugin now forwards all users to the cache first. If the page is in the cache, the visitor will see it immediately.

If not, the page generated by him is stored in the cache folder and is from now on available for all subsequent visitors. Quite simple, actually.

The simpler a caching plugin works in WordPress, the better. The more extensive the caching engine is and the more exceptions and variables it considers and knows, the more ineffective it inevitably becomes. From the small engine to the monster, which knows all kinds of plugins, dynamics and exceptions, almost everything is represented in WordPress.

Over the years I have tested them all, either out of pure interest or in the hope of finding a new interesting solution. So much "New" does not exist in the area of WordPress Caching and especially the minimal extensions have proven to be very efficient. Today, plug-ins are more about generating the paths and redirections as fast and as tiny as possible. One caching plugin does this better, the other less.

W3 Total Cache

During W3 Total Cache used to be the only serious caching plugin for WordPress that was developed by a prominent developer, the Mashable CTO Frederick Townes, the landscape of caching plugins for WordPress has fortunately changed significantly today. W3 Total Cache is now considered overloaded by most WordPress users, it is rather the solution for extremely large and complex blogs that need such a powerful caching engine at all.

WP Rocket

WP Rocket is currently probably one of the best known and most frequently used caching plugins - although the statement "caching plugin" is no longer current. In fact WP Rocket has developed into a solution that addresses many other aspects of WordPress performance optimization besides caching.

With simplicity, high compatibility and active support, WP Rocket convinces many customers, even though the plugin is only available as a paid extension.

From my point of view, the main reason for the extreme success of WP Rocket is its extremely easy handling. While a W3 Total Cache looks as if you have to configure the settings for a spacecraft shortly before the moon flight, WP Rocket only offers a few settings that are explained in a short and understandable way.

Also the, in my opinion, best compatibility regarding settings like Minimize, Defer Parsing JS and Co. convince the customers. With many other plugins you feel like you're shooting the page much faster.

cache enabler

If you want it even faster and even easier, you should still go to cache enabler grab. The WordPress Caching Plugin builds on the very minimalistic caching extension Cachify on. In contrast to WP Rocket, the plugin comes with much less optics and also less functionality. But if you are only interested in the most effective caching - then Cache Enabler is the better choice, because at least in my own tests Cache Enabler could handle far more requests in a stress test than the competition.

Recommendation: If you want support and some Schnick Schnack (Lazy Load and Co), buy a license for WP Rocket.

In the meantime, I actually advise against all other caching plugins, because I have either had bad experiences or simply don't see any added value compared to the solutions mentioned. As method you should always choose the Disk Cache, i.e. the HDD Cache in the options.

Memory, APC and Co. have proven to be inefficient in many cases and the right configuration is not always understandable or easy to implement for normal users, especially since compatibility problems can then arise again.

Raidboxes, for example, even offers server-side caching, so you can do without a separate plugin solution.

👍 20% Discount on the first 3 months on raidboxes? Then use our code "fastwp" when ordering. Click here to go to Raidboxes*

Browser Caching with .htaccess

If you have successfully installed and configured a caching plugin for WordPress, you have already done the most important things. Actually, the browser cache is even more important, because it determines whether a file has to be reloaded from the server or the copy remains in the cache of the browser and can be used from now on. To clarify the whole again, the following example: You are surfing on a website and see a great picture.

The image has poster dimensions, i.e. a very high resolution, and loading takes about 10 seconds. Bit by bit the graphic builds up slowly in front of you and when it is finally fully loaded, you are thrilled. The picture is so great that you want to show it again to your sister when she comes home from work in the evening. When she comes and you bring the laptop on the couch, you immediately hope that it doesn't take another 10 seconds until the picture is shown.

When you call it, it will appear immediately, you didn't even have to wait 1 second. Why? Because the first time the picture had to be loaded from the server, but the second time it was already in the browser cache and therefore on your hard disk, so it could be displayed directly. There was no need to connect to the server again, nor was there any need to download the image again.

How the perfect htaccess should be built up you will find out in our article the ultimate htaccess for WordPress

Understand? The browser cache stores images, pages, files, everything that a website brings with it. Depending on the webmaster's settings, the user does not need to reload the files in the cache from the server when visiting the site again, but already has a local copy on his own hard disk. So the browser automatically saves the page and keeps it as long as the browser cache of the respective website allows.

This is very practical, not only for the user who doesn't need loading times for these files anymore, but also for you as a webmaster, because you can reduce the server load extremely. If the image is on the user's computer, it does not have to be downloaded from the server. The result: The user has less loading time and the webmaster generally increases the performance, because the server is relieved significantly. Win-win situation for everyone.

The most commonly used method for browser caching, are the so-called cache control headers. These determine the exact sequence of a file, so that it remains in the browser cache of the respective visitor for only one week, one month, one year, or perhaps only for one hour. So you should consider how often your content changes and adjust the value accordingly.

The browser cache cannot be emptied remotely, so it only empties itself when the user deletes it or the cache reload is forced by repeated reloading. That means: If you set the browser cache for HTML pages to one year by mistake, the user will see the same page for a year in the worst case, because the cache is valid for that long and he normally doesn't renew it for the page. So think before, then implement.

But back to the mentioned cache control headers, which can be defined within the .htaccess file. With these headers it is possible to set the expiration time of all files and also to set a default. The Cache-Control Headers set a "max-age" value, i.e. a value that specifies how long the cache remains valid. This value is always specified in seconds, which leads to the following values:

  • One minute: max-age=60
  • One hour: max-age=3600
  • One day: max-age=86400
  • One week: max-age=604800
  • One month: max-age=2628000
  • One year: max-age=31536000

Apart from the time span, there is another value within the cache control headers. With "public", "private" and "no-store"...because we're still determining the type. With "public" basically everything is allowed, so the cache is created normally and this value is more or less the default. "pirvate" is used for pages that look different for each visitor or contain special content adapted to each visitor. "no-store" on the other hand means that the cache should not store this area under any circumstances and in any form. Basically it is the same as "private"except that there is no exception for User Agent Caching.

But what exactly does a cache control header look like? What do you really need to insert in your .htaccess to use the browser cache effectively? I'm getting to that now, because now we add the upper parameters to a finished code. In the example, images are cached for one year, CSS and Javascript files for one month, and everything else for one hour. Of course, you can adapt and change this code freely, so that file types and times are adapted to your blog and the typical time span for updates.

 Header set Cache-Control "max-age=31536000, public"   Header set cache control "max-age=2628000, public"  Header set cache control "max-age=3600, public" 

To use the browser cache also for HTML pages has become very rare, but is absolutely recommended by me. Let's assume you publish one article per day in your WordPress blog. Every day at exactly 12:00. At 11:59 a visitor comes to your blog and the HTML page ends up in your browser cache. This means that he won't see the new article at 12:00, because when he comes back to your page at 12:15, he still sees the browser cache, because we had specified a validity of one hour.

In plain language this means: The page is in his cache for one hour, the new article is not seen until 12:59, one hour after the call, because only then the version in the cache loses its validity. Is that bad now? No, because if you don't publish time-critical content or news, it doesn't matter if the article is read at 12:00 noon or 12:59 noon.

The advantage of such cache times is big, because during the whole hour the corresponding visitor does not even download anything from your server, which relieves the server accordingly. Therefore I personally always recommend long cache times.

But note the note above: Files in the cache may not be easily swappable and will not be renewed until they expire.

If the page requested by the browser is already in the cache, contact with the web server is no longer necessary. The page is loaded completely from the browser cache. There is no faster way and the server load is zero.

Server-side WordPress Caching

The topic of server-side caching should definitely not be approached by a beginner, because too much can be screwed up. The pro doesn't need any knowledge and so I will limit myself to the simple explanation of the whole thing. Server-side caching is basically based on the fact that the server takes over the caching of a website and distributes the resources accordingly cleverly.

This is realized with different modules, which must be configured correctly depending on the application area. For WordPress Blogs this is also conceivable, because most Managed WordPress Hosters rely on a server-side solution and in return prohibit caching plugins, as these then endanger the compatibility again or even cause real problems.

An example would be the provider WP Engine, which has developed its own technology called EverCache and prohibits any kind of caching plugin, because the servers themselves effectively and precisely take care of the caching issue. So if you don't want to deal with all this at all, you can simply host your blog at Raidboxes and save yourself the trouble. Raidboxes instead of WP Engine because Raidboxes is a German service, with German servers and appropriate connection.

A little info here by the way: Not everything that is called Managed WordPress Hosting is also real Managed WordPress Hosting. Mostly it is just a "fake package" with WordPress preinstalled or something similar, but then there are hardly or no adjustments on the server itself.

Real Managed WordPress hosters like Raidboxes also customize the servers and optimize everything so that it works perfectly with WordPress and compensates its weaknesses. But back to the topic: With server-side caching there are many small details to consider and beginners should simply leave it alone. Maybe I will expand this paragraph in the future and illuminate it in detail to give some tips for server-side caching.

Is caching a Google ranking factor?

As is now known, Google evaluates the performance of a website as a ranking factor. This includes the basic loading times, but also the reaction time or response time of the server itself. Both can be perfected with the right WordPress Caching. If the caching plugin is set up cleanly and correctly, the speed of your own blog increases enormously.

The result is that the server is relieved of workload and can again offer faster response times. So WordPress Caching is not only an advantage for the readers of your own blog, but with perfect performance you will always improve your Google ranking. Caching is a very important and easy to control aspect, especially because WordPress offers many plugins as ready-to-use solutions. Quite simply.

Efficient WordPress Caching

Because the topic of caching, especially in relation to WordPress, is a rather complex one, it was my concern to break it down in detail and to shed light on certain aspects of the whole thing. I hope this page will serve its purpose and help especially beginners to understand the topic WordPress Caching and Caching in general better.

For many people it is still completely unknown and there are still a lot of WordPress blogs that do not use a caching plugin. This is often based on inexperience, because not everyone reads the topic and WordPress is a CMS for beginners, who often don't think outside the box.

But in the end, having a blog means more than just writing an article every now and then. You also have to keep an eye on the technology, the performance and of course the general security.

About Christian

My name is Christian and I am co-founder of the platform fastWP. Here in the magazine I am responsible for the more "technical" topics but I like to write about SEO, which has been my passion for over 10 years now.

Leave a Comment

Your email address will not be published. Required fields are marked *

en_GB