Once basic caching is in place, the biggest remaining wins are server-level: a persistent object cache cuts database queries by 60–90% on repeat visits, and PHP 8.3’s OPcache and JIT improvements add another 15–25% on top of that — neither shows up in a caching plugin’s settings screen. Page caching solves the easy half of the problem. This is the other half.
Why Page Caching Alone Stops Working
Page caching serves a pre-built HTML file and skips PHP and the database entirely — a 10 to 20x speedup for pages that don’t change often. That’s the right first move, and it’s most of what a plugin like LiteSpeed Cache gives you out of the box. The problem is what it doesn’t touch: logged-in users, WooCommerce carts, membership content, search results, any page built from a query string, and the admin dashboard itself all bypass the page cache completely, hitting PHP and MySQL on every single request.
On a content site that’s a smaller problem. On anything with logged-in users or dynamic filtering, it’s the entire performance story — and it’s exactly the layer that basic caching plugins don’t reach.
Object Caching: The Highest-Leverage Change Most Sites Skip
WordPress’s default object cache only lives for the duration of a single request — it doesn’t persist between visitors. A persistent object cache, backed by Redis or Memcached, keeps database query results in RAM across requests instead, and the measured impact is significant: 60–90% fewer MySQL queries on repeat visits, 30–70% faster admin-area loads, and 20–50% faster frontend loads on pages the page cache can’t serve. One published case study on a 50,000-user LearnDash site found Redis plus a page cache handled peak load 8x higher than before, with database CPU usage dropping 70%.
| Layer | What it caches | Typical impact |
|---|---|---|
| Page cache | Final rendered HTML | 10–20x on cacheable pages; zero effect on logged-in/dynamic pages |
| Object cache (Redis/Memcached) | Database query results | 60–90% fewer DB queries; 30–70% faster admin, 20–50% faster uncached frontend |
| OPcache | Compiled PHP bytecode | Eliminates recompilation on every request; compounds with PHP 8.3’s JIT for 15–25% over PHP 8.0 |
Setup is three steps: install Redis server-side, add the Redis Object Cache plugin, and it auto-installs the object-cache.php drop-in that WordPress checks for automatically. Redis is the better default for most 2026 WordPress sites over Memcached because it persists data and handles WooCommerce session state more reliably; Memcached remains a fine, lighter option for plain content sites with no cart or membership logic.
PHP Version and OPcache: The Free Speedup Most Sites Leave on the Table
PHP 8.3 delivers 15–25% faster execution than PHP 8.0 through JIT compilation improvements alone — a change that costs nothing and requires no code changes, just a PHP version switch in cPanel or your host’s control panel. WordPress 7.0 recommends PHP 8.3 as the practical minimum in 2026, and any site still running PHP 8.1 or lower is absorbing a compound penalty: slower execution and a version with less security support runway.
OPcache is the other half of that layer, and it’s frequently misconfigured rather than missing entirely. It saves precompiled PHP bytecode in memory so scripts don’t recompile on every request — but a hit rate below roughly 95–98% signals the memory or file limits are set too low for the site’s plugin count. It’s checkable directly: a small PHP file calling opcache_get_status() reports the current hit rate, memory usage, and eviction count.
Finding the Actual Bottleneck Before Optimizing
Two numbers tell you which layer to attack first: Time to First Byte (TTFB) and what Query Monitor shows for slow, repeated database queries. If Query Monitor shows the same query firing dozens of times per page load, that’s an object-caching problem, not a hosting problem — Redis fixes it directly. If TTFB stays above 600ms even with PHP 8.x, OPcache, and page caching all correctly configured, the bottleneck has moved to the host itself: shared hosting with CPU throttling or slow disk I/O can’t be optimized away with more plugins, and that’s a signal to move to managed WordPress hosting with NVMe storage and dedicated resources.
This diagnostic step matters more than any individual fix, because it determines whether the next hour is spent on caching configuration or on a hosting conversation. It’s also the missing piece in most basic-caching guides, which assume the fix is always plugin-level — the fuller walkthrough of that layer is in How to Fix a Slow WordPress Website, Step by Step, and how speed maps to actual Google ranking impact is covered in Is Website Speed a Google Ranking Factor?.
If the site in question is running Elementor or another visual builder, the runtime overhead from the builder itself is frequently the actual source of a bloated TTFB and heavy JS — worth ruling in or out using the comparison in Elementor vs Custom Code: When Should a Developer Build Custom? before assuming the server is at fault.
A Practical Order of Operations
- Confirm PHP 8.3+ and check OPcache’s hit rate. Free, no code changes, and it’s frequently already misconfigured even on sites that think caching is “handled.”
- Add a persistent object cache if the site has logged-in users, WooCommerce, or membership content. Skip this step only for simple content sites with no dynamic, per-user pages.
- Run Query Monitor and look for repeated queries. This tells you whether the next fix is code-level (a plugin doing redundant queries) or infrastructure-level (add Redis).
- Measure TTFB after 1–3. Above 600ms at this point means the hosting tier itself is the ceiling, not the WordPress configuration.