WordPress performance discussions often treat “cache” as though it were one thing. It is not. A fast WordPress stack can use several caches at once, each avoiding a different kind of repeated work.
A page cache can avoid running WordPress for an entire request. An object cache can stop WordPress repeatedly asking the database for the same application data. OPcache avoids recompiling PHP scripts on every request. Database caching operates lower in the stack and helps MySQL reuse data or results efficiently.
The important question is not “do we have caching?” It is “which work are we avoiding, and at what layer?”
Where each cache sits in a WordPress request
A simplified request for a WordPress page can pass through several layers before a response reaches the visitor:
Not every request reaches every layer. That is precisely why the layers matter. A page served from Nginx cache never needs PHP, WordPress, Redis or MySQL for that request.
Page cache: avoid generating the page again
Page caching stores the final HTML response produced for a URL. When another suitable request arrives, the web server can return that response directly rather than asking WordPress to build it again.
For a public page that does not need to change per visitor, this is usually the biggest performance shortcut available. PHP does not need to start, plugins do not need to execute and the database does not need to be queried just to reproduce the same output.
What page cache is good at
- Public pages that are largely identical for every visitor.
- Absorbing repeated traffic without repeatedly executing WordPress.
- Reducing PHP worker and database load as well as response time.
What page cache cannot blindly cache
Logged-in sessions, baskets, checkout flows, account pages and other personalised or stateful requests often need to bypass full-page caching. Good caching therefore depends as much on correct exclusion and invalidation rules as it does on storing responses.
Object cache: avoid repeating WordPress data work
When a request does have to reach WordPress, the application repeatedly works with options, post data, metadata, query results and other objects. WordPress has an object cache API for this data, but without a persistent backend the cache normally lasts only for the current request.
A persistent object cache such as Redis allows useful objects to survive between requests. Instead of WordPress asking MySQL for the same information again, it can often retrieve it from memory.
This does not replace page caching. Page cache tries to avoid running WordPress at all. Object cache makes the WordPress requests that still need to run less expensive.
OPcache: avoid recompiling PHP
WordPress, its plugins and its theme are PHP programs. PHP source code must be compiled into executable bytecode before it can run. PHP OPcache keeps that compiled bytecode in shared memory so subsequent requests can execute it without recompiling the same files.
OPcache therefore solves a different problem from Redis. Redis can cache WordPress data; OPcache caches compiled PHP code. A healthy PHP deployment normally uses OPcache regardless of whether full-page or object caching is enabled.
Database cache: make the data layer efficient
MySQL also maintains memory structures and caches that reduce disk work and make frequently accessed data cheaper to retrieve. Modern database performance is not simply a matter of adding a generic “query cache”; it depends on buffer management, indexes, query design, working-set size and the behaviour of the application above it.
For WordPress, this is another reason not to confuse database caching with a persistent WordPress object cache. Redis can prevent some database queries from being issued in the first place. MySQL’s own caches make the queries that do arrive more efficient.
How the layers work together
The layers are complementary. Consider two requests to the same site.
A visitor requests a cacheable public article. Nginx already has a valid page-cache entry, so it returns the HTML immediately. PHP, WordPress, Redis and MySQL do no work for that request.
A logged-in administrator requests a page that must remain dynamic. The page cache is bypassed, but PHP can reuse compiled code from OPcache, WordPress can retrieve persistent objects from Redis, and MySQL can efficiently serve whatever data still has to be queried.
That is why comparing page cache with object cache as though one should replace the other misses the point. They optimise different stages of the same request path.
Cache invalidation matters as much as cache speed
A cache is only useful while its contents are valid. Publishing or editing content, changing a menu, updating a product or modifying application state can require cached data to be expired or refreshed.
A platform should therefore have predictable purge behaviour. Clearing everything on every small change throws away much of the benefit of caching; failing to clear the right entry can serve stale content. The goal is to invalidate the smallest appropriate scope while keeping the process understandable and recoverable.
Preloading changes who pays for the first request
After a page cache is purged, the first visitor can otherwise become the request that rebuilds it. Cache preloading or warming requests important pages in advance so their generated responses are ready before normal traffic reaches them.
This is particularly useful after deployments, content changes or broad cache purges. It does not make WordPress generation free; it moves that work away from the visitor who would otherwise wait for it.
Common caching misconceptions
“Redis makes every page load come from memory.”
No. Redis object caching helps WordPress reuse application data. WordPress still has to execute for a dynamic request, and it may still need to query MySQL for data that is not cached.
“If page cache is enabled, Redis is unnecessary.”
Not necessarily. Logged-in, uncached and deliberately excluded requests still reach WordPress. Object caching can materially reduce the work those requests perform.
“OPcache caches WordPress pages.”
No. OPcache stores compiled PHP bytecode. It reduces PHP compilation overhead but does not store the final HTML page or WordPress objects.
“More cache is always better.”
No. A cache needs memory, invalidation rules and operational visibility. Caching the wrong content or retaining it for the wrong length of time can create correctness problems rather than solve performance problems.
How Webcore approaches WordPress caching
Webcore treats caching as part of the hosting stack rather than a single WordPress switch. Nginx can serve cached public pages before WordPress starts, Redis provides persistent object caching for application requests, and PHP OPcache keeps compiled PHP available to workers. Cache preloading can warm important pages after invalidation.
The result is not that every request follows the same fast path. It is that each request should do only the work it actually needs to do.
See Managed WordPress Hosting for the managed service, WordPress for Developers & Agencies for development workflows, the Webcore Platform for the underlying infrastructure, or Webcore Panel for the control platform.