Blog · Article

Caching explained: page cache, Redis object cache and CDN, in plain terms

The word cache shows up everywhere in WordPress, but it is used for at least three different things that solve different problems. Page cache, object cache and CDN are not the same layer, and they do not help with the same bottleneck. This guide explains the three in plain terms: what each one actually does, which problem it solves, and when it is worth adding. The goal is that you can talk to your host or developer and know what you are asking for, instead of turning everything on and hoping.

Page cache: the biggest lever

Page cache is the layer most people mean when they say “cache”. An ordinary WordPress page is rebuilt from scratch on every visit: PHP runs, the database is queried, and the HTML is created anew each time. With page cache, the finished HTML page is saved after the first visit and served straight to the next visitor, without PHP or the database even starting. That is why page cache gives the most effect for the least work on most sites.

The catch is dynamic pages. A cart, a checkout or a logged-in view must not be served from cache, because it is personal. The solution is page cache with rules: cache everything except the pages and states that must be live. On Celestio this is exactly how the platform is built, full page caching where you control the rules so checkouts and logged-in views stay dynamic while everything else is cached.

Object cache: for the database work

Object cache solves a different problem. Even when a page cannot be page-cached, WordPress repeats the same database queries over and over. An object cache layer, often built on Redis or Memcached, stores the results of those queries in memory so they do not have to run again. It helps especially on sites with a lot of dynamic content, such as a store or a membership forum, where page cache is not enough.

Important to understand: a persistent object cache is a layer that runs on the server, not a plugin you simply install. Redis or Memcached has to be present and running at the host level, and then WordPress is connected to it. That is why object cache is a question to ask your host, not something you solve in wp-admin on your own. On a simple blog it rarely gives much, but on a heavy, dynamic site it can be the difference.

Page cache removes the work of building the whole page. Object cache removes the work of asking the database the same thing again. A CDN removes the distance between the server and the visitor. Three different problems, three different layers.

CDN: for the distance

A CDN, Content Delivery Network, solves a geographic problem. Your server sits in one place, but your visitors can be anywhere. A CDN is a network of servers around the world that store copies of your static files, such as images, CSS and JavaScript, and serve them from a location near the visitor. That shortens the distance and offloads your origin server.

A CDN is a separate layer you put in front of the site, often a service of its own that you connect. It is most worthwhile when you have visitors spread across several countries or a lot of heavy static media. If you mainly have a local audience and a server that already sits nearby, a CDN makes less difference, because the distance is already short. Decide based on where your visitors actually are, not because it sounds modern.

Which layer solves your problem?

  • The site is slow for logged-out visitors? Start with page cache. It is almost always the right first step.
  • The site is slow logged in, in the admin or at checkout? Page cache does not help here. Look at object cache and at the database.
  • Visitors far away find the site sluggish, but nearby ones do not? Then a CDN is worth considering.
  • Not sure what the bottleneck is? Measure first. Caching at the wrong layer does not solve the problem.

Caching is not a magic button but three different tools for three different problems. Understand the difference and you do not waste time on the wrong layer. If you want to read more about where slowness actually comes from, we have written about why a WordPress site is slow and about how to pass Core Web Vitals. Our platform ships with full page caching and rules you control as part of the foundation, and you can start an account to move the site across.