Website Caching Explained: Five Caches and How They Stack

The word “cache” turns up everywhere once you start looking at site speed. There is a Clear Cache button in your WordPress admin bar. A speed test tells you to “serve static assets with an efficient cache policy”. Your host’s sales page promises “built-in caching”. A developer mentions Redis. It sounds like one thing with many names, and it is not.

This is website caching explained from the ground up, using one ordinary page view as the thread. Once you can picture the layers, speed reports and plugin settings stop reading like a foreign language.

What a cache is, in one idea

A cache keeps the result of some expensive work so it does not have to be done again. That is all. A calculator that remembers the answer to a long sum, a receptionist who keeps the five most-requested forms on the desk instead of walking to the filing room every time: both are caches.

Every cache on a website answers three questions, and it helps to ask them every time you meet a new one:

• What does it store? Finished pages, single files, database answers or compiled code.
• Where does it live? On the visitor’s device, on a server somewhere between you and them, or on your own hosting server.
• When is the stored copy thrown away? After a set time, when you press purge, when the content changes, or when the cache runs out of room.

The third question is where most real-world trouble comes from. A cache that keeps copies too long shows old content. One that keeps them too briefly barely helps.

Website caching explained as a chain of shortcuts

To see why there are several caches rather than one, follow a single visit to a WordPress page with no caching at all.

1. The visitor’s browser asks your server for the page.
2. The server starts PHP, which reads hundreds of WordPress, theme and plugin files and turns them into instructions it can run.
3. That code asks the database for the page content, menus, widgets, settings and anything plugins need. On a busy page this can be a long list of queries.
4. PHP assembles the answers into an HTML page and sends it back.
5. The browser reads the HTML and then requests every stylesheet, script, font and image it mentions.

Each of those steps has its own shortcut. Step 2 is shortened by an opcode cache. Step 3 by an object cache. Steps 2 to 4 together can be skipped entirely by a page cache. Step 5 is shortened by a CDN, which puts the files closer to the visitor, and by the browser cache, which keeps them on the visitor’s own device for next time. Nothing here is exotic. It is the same trick applied at five different points in the journey.

The types of website cache, nearest to the visitor first

Browser cache

The visitor’s browser keeps copies of files it has already downloaded: your logo, stylesheets, scripts, fonts. On the next page, or the next visit, it uses its own copy instead of asking again. It does nothing for someone’s very first page view, but it makes every page after that cheaper.

You do not control the browser directly. Your server sends instructions with each file, in response headers, saying how long the copy may be kept. That is what speed tools are complaining about when they flag short cache lifetimes, and it is covered properly in our post on browser caching and cache-control headers. One consequence worth knowing now: you cannot reach into a visitor’s browser and delete its copy. That is why sites add version numbers to file addresses when a file changes.

CDN or edge cache

A content delivery network keeps copies of your files on servers in many cities, so a visitor’s request does not have to travel all the way to your hosting. By default most CDNs store static files such as images, CSS and JavaScript. Some can also store whole HTML pages, which is powerful and needs care. If the idea of a CDN is new, our explainer on what a CDN does and when a small site needs one covers the basics. For the common Cloudflare setup on WordPress, see how Cloudflare caching behaves on a WordPress site.

Page cache

A page cache stores the finished HTML of a page, so the next visitor gets it without PHP or the database being involved at all. For a typical brochure site or blog this is the cache that makes the biggest difference to how quickly the server answers.

It can live in two places. A caching plugin may write each page to a file on disk and serve it early, before most of WordPress loads. Or the web server itself may keep the pages, as with LiteSpeed’s built-in cache, Nginx’s FastCGI cache or Varnish in front of the site. Many hosts run one of these for you. Either way, a page cache must skip anything personal: logged-in users, carts, checkouts, account pages. The details, including what to exclude and how long pages should be kept, are in our guide to page caching in WordPress.

Object cache

An object cache stores the answers to database questions and other computed values, so that the same query does not have to be run again. WordPress always has one, but by default it only lasts for a single page load and is then thrown away. A persistent object cache, usually Redis or Memcached, keeps those answers in memory between requests.

This matters most where a page cache cannot help: logged-in members, shop customers with something in the cart, the admin area, search results. We explain when it is worth asking your host for it in Redis object caching for WordPress.

Opcode cache

PHP files are plain text. Before PHP can run them it has to compile them into lower-level instructions. An opcode cache, which for modern PHP means OPcache, keeps the compiled version in the server’s memory so that work is done once rather than on every request. It is usually switched on by the host and you rarely see it. When it is missing or starved of memory, every uncached request pays for it. Our note on what PHP OPcache does explains how to check.

All five at a glance

How the layers work together on real visits

The layers do not compete. Each one handles the requests the layer above could not.

A first-time visitor from a search result. Their browser has nothing stored. The CDN, if you have one, may already hold your images and CSS. The page cache hands over the HTML straight away. PHP, the database, OPcache and Redis are not touched at all for that HTML.

The same visitor clicking to a second page. Now the browser cache earns its keep. The logo, fonts, stylesheet and main scripts are already on their device, so only the new HTML and any new images need to arrive.

A logged-in member or a shopper with items in the cart. The page cache steps aside, because the page has to show their name, their cart, their prices. Every request now runs PHP. This is where OPcache and a persistent object cache carry the load. On a membership site or a busy shop, these quiet lower layers matter more than the visible plugin.

You, editing in wp-admin. Nothing in the admin is page cached. Opcode and object caching are the only help you get.

That last point explains a common puzzle: a site that scores well in a speed test, run as an anonymous visitor, but feels slow to the people who log in. The test only ever saw the top layers.

Finding out which caches you already have

Before adding anything, check what is already running. Many sites have two or three layers without the owner knowing.

1. Look at the response headers. In Chrome, open DevTools, go to the Network tab, reload the page and click the first request. Headers such as cf-cache-status (Cloudflare), x-litespeed-cache, x-cache or age show that some layer is storing pages. The names differ between hosts and CDNs, so treat any header mentioning cache as a clue rather than an answer.
2. Check your hosting panel. Managed WordPress hosts often have a caching section with its own purge button, sometimes added to the WordPress admin bar.
3. Check your plugin list. Look for anything with cache, rocket, optimise or performance in its name. More than one page caching plugin is a problem in itself.
4. Look in wp-content. A file called advanced-cache.php means a page caching plugin has hooked in early. A file called object-cache.php means a persistent object cache is set up, or was set up once and left behind.
5. Ask your host whether OPcache is enabled and whether Redis or Memcached is available on your plan.

Write down what you find. If you later hire someone to work on speed, this list saves the first hour of their time.

Where caching goes wrong

• Two layers doing the same job. A host page cache plus a plugin page cache, or two caching plugins, can serve different versions of the same page and make purging unpredictable.
• Personal pages cached for everyone. A cart, an account page or a “Hello, Priya” banner stored in a page cache or at the CDN can be shown to the next visitor. This is the most serious caching mistake and it is entirely avoidable with the right exclusions.
• Lifetimes set without thought. HTML kept for weeks shows stale content. Images kept for an hour are downloaded again for no reason.
• Purge habits that defeat the cache. Clearing everything after every small edit means visitors keep landing on freshly emptied caches and meeting the slow, uncached version.
• Optimisation bundled with caching. Many caching plugins also minify, combine and delay files. Those are not caching features, and they are the ones that most often break layouts.

What caching cannot do for you

Caching makes repeated work cheaper. It does not make the work itself lighter. A page with eight megabytes of images is just as heavy when the HTML comes from a page cache. Twenty third-party scripts still run in the visitor’s browser. A slow database query still runs for every logged-in user if nothing stores its result. Caching is usually the first big step on a WordPress site, and our website speed guide sets it alongside the other areas that decide how fast a page feels: images, code, server and third parties.

Frequently asked questions

Is clearing the cache bad for my website?

Clearing a cache is harmless in itself. Nothing is lost, because every cached copy can be rebuilt. The cost is speed: the next visitors to each page get the slow, uncached version until the cache fills again. Purge after real changes, such as a new menu or design, rather than after every small edit.

Does caching help a site with very little traffic?

Yes, though in a slightly different way. On a quiet site each page may only be visited occasionally, so cached copies can expire before anyone uses them. Longer page cache lifetimes and preloading help there. Browser caching and OPcache still help every visitor regardless of traffic levels.

Can caching show one visitor’s details to another?

It can if pages that contain personal information are stored in a page cache or at a CDN. Carts, checkouts, account pages and anything shown only to logged-in users must be excluded. Good caching plugins and hosts exclude the standard ones, but custom pages and some plugins need manual exclusions.

Do I need every type of cache on my site?

Not necessarily. Most WordPress sites benefit from browser caching, a page cache and OPcache, which many hosts already provide. A persistent object cache matters mainly for stores, membership sites and busy admin areas. A CDN matters most when visitors are far from the server or pages carry many images.

Mapping which caches a site already has, and whether any of them is storing pages it should not, is usually the first part of the audit in our website speed optimisation work. You get the findings as a prioritised list, and nothing changes until you approve it.

All guides in this section

• Page Caching in WordPress: How a Full Page Cache Works
• Leverage Browser Caching: Cache-Control Headers Explained
• Redis Object Cache for WordPress: When It Is Worth It
• PHP OPcache Explained: The Cache Your Host Runs for You
• How to Choose a WordPress Caching Plugin for Your Server
• LiteSpeed Cache Settings: A Safe, Staged Setup
• Caching WooCommerce Cart and Checkout: What to Exclude
• Cache Preloading Explained: Warm Up Your Website Cache
• Cloudflare Caching for WordPress: Defaults, HTML, Purging
• Caching Plugin Broke My Site: Safe Rollback and Fixes

Next in this series: Page Caching in WordPress: How a Full Page Cache Works