{"id":20412,"date":"2026-11-02T12:27:10","date_gmt":"2026-11-02T11:27:10","guid":{"rendered":"https:\/\/stage.surver.nl\/kennisbank\/wordpress-caching-uitleg\/"},"modified":"2026-11-03T12:13:53","modified_gmt":"2026-11-03T11:13:53","slug":"wordpress-caching-explained","status":"publish","type":"kennisbank","link":"https:\/\/stage.surver.nl\/en\/kennisbank\/wordpress-caching-uitleg\/","title":{"rendered":"Caching in WordPress: Types and Configuration"},"content":{"rendered":"
\"Caching<\/figure>\n\n\n\n

Every speed optimization guide says, \u201cInstall a caching plugin,\u201d but which one, and what does it actually do? WordPress has four caching layers: browser caching, page caching, object caching for database queries, and server caching, such as LiteSpeed. Page caching delivers the biggest performance gains, while object caching is particularly useful for online stores and logged-in users. Below, you\u2019ll learn which layers you need and how to set up caching without breaking your online store. Caching is one of the steps in How to Speed Up WordPress: The Complete Guide<\/a>.<\/p>\n\n\n\n

What is caching?<\/h2>\n\n\n\n

Caching is the process of storing a pre-generated result so that it doesn't have to be recalculated every time a visitor accesses the page. Without caching, WordPress builds each page from scratch for every visitor. The server runs the PHP code, retrieves the content from the MySQL database, assembles everything, and only then sends back the HTML. With caching, that work is done only once, and subsequent visitors receive a cached HTML copy. This reduces the computational load, so the server can handle higher traffic for longer, and the TTFB\u2014the time to the first server response\u2014is reduced.<\/p>\n\n\n\n

I always explain it using the example of a baker. He prepares his best-selling loaves first thing in the morning, instead of baking each loaf only when a customer walks in. He does, however, bake a custom-ordered cake fresh, and in WordPress, those are the shopping cart and the checkout. I\u2019ll come back to that later. The downside of pre-baked bread is that it doesn\u2019t refresh automatically. If you make a change and still see the old version, you\u2019ll need to clear the cache. You can read about how that works at Clearing the Cache in WordPress<\/a>.<\/p>\n\n\n\n

The Four Caching Layers at a Glance<\/h2>\n\n\n\n

Each of the four layers stores something different in a different location, and they complement each other rather than replace one another.<\/p>\n\n\n\n

Low<\/th>What Is Stored<\/th>Where<\/th>Who sets it up?<\/th><\/tr><\/thead>
Browser Caching<\/td>Images, CSS, JavaScript<\/td>Visitor's browser<\/td>Caching plugin or server<\/td><\/tr>
Page Caching<\/td>Complete HTML pages<\/td>Server<\/td>Caching Plugin<\/td><\/tr>
Object caching<\/td>Results of database queries<\/td>Working Memory (Redis, Memcached)<\/td>Hosting Plus Plugin<\/td><\/tr>
Server Caching<\/td>Pages, even before WordPress starts<\/td>Web Server (LiteSpeed)<\/td>Hosting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Browser caching stores static files in your visitor's browser, with an expiration time. The server specifies this in headers such as Cache-Control with max-age, Expires, and ETag. If a visitor returns and a file hasn\u2019t changed, the server responds with a 304 status code instead of resending everything. You\u2019ll notice this especially with returning visitors.<\/p>\n\n\n\n

Page caching stores entire HTML pages so the server doesn\u2019t have to rebuild them for every visitor. This provides the greatest benefit for visitors who aren\u2019t logged in\u2014which, on most sites, is virtually everyone. My advice, therefore, is to start here. In addition, there\u2019s OPcache, which caches compiled PHP code, and CDN caching on servers located around the world. Your hosting provider handles the former; at Surver, OPcache is enabled by default.<\/p>\n\n\n\n

Object caching and server caching: When do you need them?<\/h2>\n\n\n\n

Object caching stores the results of database queries in memory\u2014usually via Redis or Memcached\u2014and helps precisely where page caching falls short. A WooCommerce store, a membership site, or your own dashboard is difficult to cache as an HTML copy because the content varies by visitor. In such cases, it makes a big difference if the database doesn\u2019t have to answer the same query over and over again. In Site Diagnosis, WordPress sometimes recommends a persistent object cache. This requires Redis or Memcached on the server, and with Surver, Redis is only available on Surver Cloud<\/a>. On shared hosting, you can safely leave that message as is as long as your page caching is set up correctly. You can find more information in Object Caching and Redis Explained<\/a>.<\/p>\n\n\n\n

Server caching is caching performed by the web server itself, such as LiteSpeed or Varnish. This is faster than caching via a PHP plugin, because WordPress doesn't even have to start up. However, it does require that your hosting provider runs the right web server. On a LiteSpeed server, the plugin works LiteSpeed Cache<\/a> directly in conjunction with the server cache, which you don't get with other plugins. More on that in What Makes Up Fast WordPress Hosting<\/a>.<\/p>\n\n\n\n

So what do you need? For a business website or blog, page caching and browser caching are enough, along with server caching if your host offers it. A high-traffic content site with a lot of international traffic would also benefit from a CDN for WordPress<\/a>. Object caching only becomes useful for an online store or membership site with a large number of logged-in users.<\/p>\n\n\n\n

Setting Up and Checking Caching<\/h2>\n\n\n\n

You set up caching using a single caching plugin that's compatible with your web server, and then you check to see if it actually works. That's how I do it myself.<\/p>\n\n\n\n

    \n
  1. Check which web server your hosting provider uses.<\/li>\n\n
  2. Choose the plugin that's right for you. On a LiteSpeed server, that's LiteSpeed Cache; elsewhere, it could be WP Super Cache, W3 Total Cache, or WP Rocket.<\/li>\n\n
  3. Use only one caching plugin, and don't use a plugin alongside your host's cache if it performs the same function.<\/li>\n\n
  4. Enable page caching and browser caching.<\/li>\n\n
  5. Set an expiration time and have the cache preload (in LiteSpeed Cache, this is called the crawler), so that the first visitor doesn't have to wait for an empty cache.<\/li>\n\n
  6. Check the default exclusions and test while logged out in a private window.<\/li>\n<\/ol>\n\n\n\n

    That third step is more important than it seems. Two caches handling the same layer won\u2019t make your site faster\u2014they\u2019ll make it unpredictable, resulting in outdated pages and broken layouts. You can check if it\u2019s working in your browser\u2019s developer tools. Open the Network tab, reload the page twice while logged out, and check the response headers. On a LiteSpeed server, the second request will show x-litespeed-cache: hit<\/code>, other plugins send a similar header. If you don't want to set up and maintain caching yourself, then it's part of WordPress Management<\/a>.<\/p>\n\n\n\n

    Pages You Should Never Cache<\/h2>\n\n\n\n

    Pages with personal or constantly changing content should never be included in the page cache, because otherwise one visitor might see the data intended for another. Here they are.<\/p>\n\n\n\n