“Install a caching plugin” is the most common advice for a slow WordPress site. But “caching” means several different things, working at different layers, and they solve different problems. Knowing which is which explains why a site can be fast for visitors and still slow in the admin, or fast on blog posts and slow at checkout.
What happens without any cache
When someone visits a WordPress page without caching, the server:
- starts PHP and loads WordPress, your theme and every active plugin,
- runs dozens, sometimes hundreds, of database queries,
- assembles the HTML for the page,
- sends it to the visitor, and then throws all of that work away.
The next visitor to the same page causes exactly the same work. Caching is about not doing the same work twice.
The page cache: whole pages, ready to go
A page cache saves the finished HTML of a page after it is built once. The next visitor gets that saved copy straight away, without PHP or the database being involved at all.
This is the biggest speed-up WordPress can get. A cached page can be served in a few milliseconds, and a server can handle many times more visitors.
Page caching can live in a few places:
- In a plugin, which writes pages to disk and serves them through PHP or the web server.
- In the web server itself, such as LiteSpeed’s built-in cache with the LiteSpeed Cache plugin, or a reverse proxy in front of WordPress. This is usually the fastest option.
- At a CDN, which keeps copies of pages close to visitors around the world.
What a page cache cannot do
A page cache only works when many people should see exactly the same page. It must skip:
- logged-in users, including you in the admin, members and customers with accounts,
- the WooCommerce cart, checkout and my account pages, which are different for every shopper,
- anything personalised, such as pages that show a username or a recently viewed list.
For all of those, every request still runs PHP and the database. That is where the object cache comes in.
The object cache: answers to database questions
Inside every request, WordPress asks the database many questions: site options, menus, product data, user details. WordPress already keeps those answers in memory while the request runs, so it does not ask twice in the same page load. That built-in cache is called the object cache.
The catch: by default, WordPress forgets everything at the end of each request. The next page asks all the same questions again.
A persistent object cache keeps those answers in a fast in-memory store, usually Redis or Valkey, between requests. The database is asked far less often, and every uncached page gets faster:
- the admin dashboard and editor,
- WooCommerce cart and checkout,
- membership and course sites where most users are logged in,
- search results and filtered product lists.
What an object cache cannot do
An object cache does not skip PHP, so it will never make a page as fast as a page cache does. It also cannot fix slow code: a plugin that does heavy work on every page is still slow, just with fewer database waits.
The other layers
Two more caches work quietly in the background:
- OPcache keeps PHP code compiled in memory, so PHP does not reread and recompile WordPress’s files on every request. It should always be turned on, and on most modern servers it is.
- Browser caching tells visitors’ browsers to keep images, stylesheets and scripts for a while, so returning visitors download less.
Which one do you need?
| Site | Page cache | Object cache |
|---|---|---|
| Blog or brochure site | Essential | Nice to have |
| WooCommerce store | Essential for catalogue pages | Strongly recommended |
| Membership or course site | Helps public pages only | Essential |
| Busy admin, many editors | Little help | Strongly recommended |
For most sites, the answer is both: a page cache for everything that can be shared, and an object cache for everything that cannot. If your store still feels slow with both in place, our guide on why a WooCommerce store is slow covers the next things to check.
Clearing caches
Caches must be cleared when content changes, or visitors see old pages. Good setups clear the right pages automatically when you publish or update. If you change something by hand, such as theme files or settings, clear the page cache yourself, and remember any CDN in front of the site.
Where Rubuz fits
Every site on Rubuz gets both layers already set up: OpenLiteSpeed with LiteSpeed Cache for full pages, and Valkey as a persistent object cache, tuned for WordPress and WooCommerce on your own VPS.