WordPress caching means keeping ready-made copies of work your site has already done, so it doesn’t redo that work for every visitor. There are three main layers: page caching saves whole pages, object caching saves database results, and a CDN keeps copies of files closer to visitors. Most small business sites need one page cache, done well, before anything else.
Key takeaways
- Page caching gives the biggest speed gain for most sites, because pages are served without running WordPress.
- Object caching (Redis or Memcached) helps busy shops, member sites and slow admin areas most.
- A CDN mainly helps when visitors are far from your server or traffic spikes.
- Use one tool per layer. Two page caching plugins fight each other and cause odd bugs.
- Online stores must keep cart, checkout and account pages out of the page cache.
Why does WordPress need caching at all?
WordPress builds each page on request. When someone visits your home page, the server runs PHP code, asks the database dozens of questions, assembles the HTML and sends it. That takes real work, and the result is usually identical for every visitor.
Caching skips the repeated work. The WordPress handbook says a page cache can improve performance “several hundred times over for fairly static pages” (WordPress.org). Most small business sites are exactly that: pages that change a few times a month.
If your site is slow and you’re not sure caching is the cause, start with our list of reasons a WordPress site is slow. Oversized images and heavy plugins can’t be cached away.
How do the caching layers fit together?
Think of a visit as a journey from the visitor down to your database. Each cache sits at a different point and catches the request before it has to go further.
What is page caching?
A page cache saves the finished HTML of each page the first time it’s built. The next visitor gets that copy straight away, without PHP or the database being involved. This is the single biggest speed gain for most WordPress sites.
Plugin or server?
Page caching can run in two places:
- A plugin, such as WP Super Cache or W3 Total Cache, which saves pages as files. It works on almost any host.
- The web server (for example Nginx or Varnish), which serves cached pages before PHP even starts. It’s faster, and it’s the host’s job to set it up.
If your host already caches pages at server level, a caching plugin doing the same job adds nothing. Often it causes stale pages that won’t clear.
What shouldn’t be cached?
Anything personal to one visitor. WooCommerce says the cart, checkout and My Account pages must be excluded, because they “display information specific to the current customer and their cart” (WooCommerce). Logged-in users and form pages with security tokens need care too. A shop where customers see someone else’s cart almost always has a caching rule wrong.
What is object caching, and do I need Redis?
Object caching stores the answers to database questions, such as your menu, settings or product details. WordPress has an object cache built in, but by default it’s thrown away after every page load. The developer documentation says data won’t persist across page loads “unless you install a persistent caching plugin” (WordPress Developer Resources).
A persistent object cache keeps those answers in fast memory between visits. Redis and Memcached are the two common engines. It needs the engine running on the server plus a small connector plugin.
Who benefits most?
- Online stores, because carts and checkout can’t use the page cache.
- Membership and learning sites, where most visitors are logged in.
- Slow admin areas, since the dashboard is never page cached.
For a five-page brochure site that’s already page cached, Redis makes little visible difference. It isn’t harmful, but it shouldn’t be the first thing you fix.
What does OPcache do?
OPcache is a PHP feature, not a WordPress one. It keeps WordPress’s code compiled in memory, so PHP doesn’t re-read thousands of files on every request. The WordPress handbook says an opcode cache “will improve PHP’s performance by many times”. It’s normally switched on by the host, and you shouldn’t need a plugin. Running a current WordPress PHP version matters just as much, since newer PHP is faster as well as safer.
Where does a CDN fit?
A content delivery network keeps copies of your files on servers in many cities. Visitors get them from the nearest one. web.dev notes that CDNs also reduce load on your own server and help absorb traffic spikes (web.dev).
Most CDNs cache images, styles and scripts by default. Some can cache whole pages too, which then needs the same exclusions as a page cache. If your customers are all in Australia and your server is too, a CDN helps less than you’d think. Our article asking do I need a CDN works through that question.
Why do caching plugins cause problems?
In our experience, most caching trouble comes from overlap rather than a missing cache. Common patterns:
- Two page caches. A plugin and the server both cache pages, and clearing one leaves the other serving old content.
- A plugin plus a host’s own optimiser. Both minify and combine scripts, and menus or sliders stop working.
- Over-eager settings. Every option switched on, including ones that delay scripts needed by forms or checkout.
- Nobody clears the cache. Content is updated, but visitors keep seeing the old version.
The fix is to give each layer one owner. Use the server’s page cache if there is one, add object caching where it’s useful, and keep a plugin only for jobs nothing else does, such as image optimisation.
What should a good host provide?
Caching works best when it’s built into the hosting rather than bolted on. Before you add plugins, ask your host:
- Is there a server-level page cache? If yes, ask how to clear it and what it excludes.
- Is OPcache on? The answer should simply be yes.
- Can I use Redis or Memcached? Ask whether it’s included and who sets it up.
- Are WooCommerce pages excluded? Cart, checkout and account pages, plus logged-in visitors.
- How much CPU and memory do I get? Uncached requests still need real resources.
Our guide to WordPress hosting in Australia explains what else “optimised” should mean. If caching settings, plugin updates and testing feel like too much, our WordPress maintenance services look after the site side, and you can compare our hosting plans for the server side.
Frequently asked questions
What is the best WordPress cache plugin?
The best one is often none, if your host already caches pages at server level. Otherwise, choose one well-supported plugin, configure the page cache properly and leave other plugins’ caching features switched off. Avoid running two caching plugins at once.
Why does my site still show old content after I update it?
A cache is serving the old copy. Clear the page cache in your plugin or hosting panel, then the CDN cache if you use one. Check in a private browser window, which ignores your own browser’s cached files.
Does Redis help a small brochure site?
Usually only a little. If pages are already served from a page cache, the database is rarely touched. Redis helps most on online stores, membership sites and busy admin areas, where many requests can’t be page cached.
Can caching break a WooCommerce store?
Yes, if the cart, checkout or My Account pages are cached. Customers may see empty carts, someone else’s details or failed payments. WooCommerce recommends excluding those pages and its cart cookies from any page cache.
Do I need a CDN if I have page caching?
Not always. Page caching speeds up how fast your server responds. A CDN shortens the distance files travel. If your visitors and server are both in Australia, page caching usually matters more.
Sources
- Cache, WordPress Advanced Administration Handbook
- How to configure caching plugins for WooCommerce, WooCommerce Developer Docs
- WP_Object_Cache, WordPress Developer Resources
- Content delivery networks (CDNs), web.dev