WordPress caching works best when each layer has a clear job. This guide explains how to combine page caching, object caching, browser and CDN caching, and WooCommerce exclusions without serving stale or private data. It also provides a recurring checklist for checking cache behavior after plugin, theme, hosting, or configuration changes.
Overview
WordPress speed optimization is rarely solved by installing one caching plugin and leaving its default settings unchanged. A typical site can have several caching layers: the visitor’s browser, a CDN or reverse proxy, a WordPress page cache, and an object cache connected to the database. These layers can improve response time, reduce work at the origin server, and make frequently requested pages more consistent under load. They can also conflict when their rules are unclear.
The most important distinction is between page caching and object caching. A page cache stores a generated HTML response so WordPress does not need to build the same public page for every visitor. Object caching stores results from repeated database or application operations, such as options, queries, or other calculated values. Object caching can help dynamic requests, logged-in areas, and uncached pages, but it does not replace a page cache.
A CDN adds another layer by distributing cacheable assets, and sometimes HTML, closer to visitors. Static files such as images, stylesheets, scripts, fonts, and downloadable files are usually the safest starting point. Full-page edge caching can be useful for public content, but it requires careful handling of cookies, sessions, personalized content, and purges. For background on response timing, see the practical guide to improving TTFB.
Use this operating principle: cache public, repeatable responses aggressively enough to help performance, and exclude anything that depends on the visitor, current session, cart, or account state.
What to track
1. Page-cache status
Choose a small set of representative URLs and record whether each request is served from cache. Include a homepage, a standard post or page, a category or archive page, a search result, and one important landing page. Test each URL in a private browser window and after clearing cookies. A response that is fast for an administrator may not reflect the experience of a logged-out visitor.
Check the response headers exposed by your hosting platform, cache plugin, or CDN. Header names vary, but useful signals may identify a cache hit, miss, bypass, or revalidation. Do not assume that a page is cached merely because a plugin reports that caching is enabled. Confirm behavior with repeated requests and, where available, the cache-status information from the edge or reverse proxy.
2. Cache exclusions and private paths
Maintain an explicit list of paths that should not be served from a shared page cache. Common examples include login and account areas, checkout and cart pages, order history, preview URLs, and pages that display visitor-specific information. The exact paths depend on the plugins and theme installed on the site.
Also review cookie-based bypass rules. A visitor may receive a different response when a session, authentication, cart, or personalization cookie is present. If the cache layer ignores that distinction, it can serve the wrong page to the wrong visitor. If the layer bypasses too broadly, performance and cache hit ratio may suffer. Record the intended behavior instead of relying on undocumented defaults.
3. WooCommerce behavior
For WooCommerce sites, test the complete customer journey rather than only the homepage. Confirm that product pages, category pages, cart contents, checkout fields, account details, shipping estimates, payment steps, and order confirmation behave correctly. Product and category pages may be suitable for caching when their content is public, but cart, checkout, account, and order-related responses generally require special treatment.
After changing a product, price, stock status, sale schedule, or shipping rule, verify which cache layers are purged. A WordPress cache purge may not clear an independent CDN cache, and a CDN purge may not refresh an object cache. See the ecommerce CDN requirements checklist when evaluating a broader edge setup.
4. Object-cache health
Track whether the object cache is connected, whether its keys are being reused, and whether errors appear in application or hosting logs. A persistent object cache can reduce repeated database work, but stale or incompatible cached values can create confusing behavior after updates. When debugging, test whether the issue remains after clearing the object cache separately from the page cache.
5. Static assets and cache-control
Check how images, CSS, JavaScript, fonts, and downloads are cached in the browser and CDN. Versioned filenames or query-string revisioning can help ensure that a changed asset is requested again. If a file is replaced without changing its cache identity, some visitors may continue receiving the older copy until its TTL expires or the relevant cache is purged. Use the cache-control headers guide to review policies by content type.
Cadence and checkpoints
A monthly review is a practical minimum for an active WordPress site. A quarterly review may be sufficient for a stable brochure site, provided that testing also happens after material changes. Keep a short record with the date, WordPress and plugin changes, cache configuration, tested URLs, observed headers, and any purges performed.
After every plugin or theme change
- Clear the page cache, object cache, browser cache where appropriate, and CDN cache only when needed.
- Open the homepage, navigation, search, forms, and representative content pages while logged out.
- Check responsive layouts and confirm that CSS and JavaScript assets are current.
- Test login, logout, password recovery, and any user-specific widgets.
- For WooCommerce, add an item to the cart and progress through checkout in a test environment or with a safe test order process.
During the monthly review
Compare response behavior from at least two locations or networks if your team can do so, because an origin request and an edge-cache request may follow different paths. Review TTFB alongside total page load time; a fast server response does not guarantee that a page is efficient in the browser. Check cache hit and bypass patterns, purge activity, error logs, and storage limits. Look for unusual increases in origin requests after a deployment or content campaign.
Before a high-traffic event
Identify the pages likely to receive attention, confirm that public pages can be cached, and verify that dynamic paths are excluded. Warm or request key pages only if your platform supports this safely. Confirm how to perform a targeted purge and who is authorized to use it. A documented rollback plan is more useful than a last-minute change to several cache layers at once.
How to interpret changes
If TTFB rises while cache hits fall, investigate bypass rules, cookie handling, expired entries, origin errors, and recent changes to page personalization. If TTFB is stable but the page feels slower, inspect asset size, render-blocking resources, image delivery, and client-side scripts rather than changing the page cache immediately.
If visitors report stale content, identify which layer still holds the old response. Purge the smallest relevant scope, then test again from a clean session. A full purge may hide the underlying issue and create an unnecessary burst of origin traffic. Also check whether the application is sending cache-control headers that contradict the intended CDN or reverse proxy policy.
If logged-in users see public cached content, review authentication cookies and bypass rules immediately. If logged-out visitors see account or cart information, stop shared caching for the affected paths while investigating. Correctness takes priority over a higher cache hit ratio.
If performance worsens after enabling object caching, compare behavior with the object cache temporarily disabled in a controlled test. Review serialization, persistent connections, memory limits, and plugin compatibility with your hosting environment. Treat object-cache errors separately from page-cache misses; they indicate different failure points.
When to revisit
Revisit this WordPress caching plan monthly for active sites and at least quarterly for stable sites. Update it immediately after changing hosting, DNS, a CDN, a cache plugin, a theme, WooCommerce, checkout, authentication, personalization, or major content workflows. Also revisit it when monitoring shows a sustained change in TTFB, cache hit ratio, origin traffic, error rate, or customer-reported freshness.
Keep the process actionable. Maintain a list of test URLs, expected cache behavior, excluded paths, important cookies, purge commands, and the person responsible for verification. After each change, test both a clean logged-out visit and the relevant logged-in or shopping workflow. Record the result before moving to the next optimization.
WordPress caching is not a one-time switch. It is a set of rules that should remain aligned with the site’s content, plugins, users, and business workflows. A short recurring review prevents many cache-related surprises while preserving the performance benefits of page caching, object caching, and edge delivery.
