The caching stack we use on every WordPress site we manage

We have a standard caching setup that goes on every WordPress site we manage. Not because we are rigid about tooling but because site performance is a campaign performance issue, and we cannot be rigorous about one without being rigorous about the other. When a client spends thirty thousand a month on Google Ads and the landing page takes six seconds to load on a 4G connection in Nagpur, roughly half that spend is going to bounce rates.

Our stack has three layers. Object caching sits closest to the database and reduces query load. Full-page caching serves cached HTML to unauthenticated visitors, removing WordPress's PHP execution overhead from most requests. Browser caching and CDN handling sits at the edge, serving static assets from locations closer to the user and reducing time-to-first-byte for repeat visitors.

The specific tools

For object caching, we use Redis where the hosting environment supports it. On managed WordPress hosts, Redis is often available but not configured by default. Adding a Redis object cache plugin and pointing it at the Redis instance cuts database query time significantly on sites with even moderate traffic. On hosts where Redis is not available, we fall back to W3 Total Cache's database caching.

For full-page caching, we use either WP Rocket or W3 Total Cache depending on the hosting environment and whether the site is on a configuration that supports server-level caching through Nginx. WP Rocket is simpler to configure and the settings we use are documented in an internal template so any team member can apply them consistently. W3 Total Cache gives more control when we need it but requires more careful setup to avoid serving cached content to logged-in users or WooCommerce cart pages.

What we test and when

After implementing or changing cache configuration, we run PageSpeed Insights against the key pages, specifically desktop and mobile on the main landing pages that receive paid traffic. We look at Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. We want LCP under two and a half seconds on mobile for any page receiving ad traffic. Pages that miss that get investigated further: usually it is an unoptimised image, a render-blocking script, or a font loading issue.

We also use GTmetrix for waterfall charts when something looks wrong. The waterfall tells you which resource is creating the bottleneck, which is more useful than the aggregate score alone.

The cache stack is not the only performance lever. Hosting environment quality matters enormously. Image optimisation matters. Choosing a lightweight theme matters. But the cache layer is the most reliably high-return intervention, and it belongs on every site we touch from day one.