WordPress cache: how to choose, configure, and verify page cache, object cache, and CDN

WordPress caching is not a single tool. A page cache can serve prebuilt HTML, Redis can retain application data, OPcache reduces PHP compilation work, and a CDN can distribute assets or, when configured for that purpose, HTML pages from the edge.

Enabling multiple systems without assigning each one a role can leave outdated content online or incorrectly serve dynamic pages such as the cart and checkout. The starting point is to identify the request you want to speed up, decide what handles public HTML, and verify the outcome on the site’s real-world flows.

1. Choose the cache based on the problem

Quick choice

• Blog or brochure website: use the page cache already provided by your hosting provider or a single page caching plugin. Add browser caching and a CDN for assets.
• WooCommerce site: cache the catalog and public pages, but exclude the cart, checkout, account pages, and session requests. Consider Redis only if the admin area or dynamic requests show a bottleneck.
• Membership, e-learning, or intranet site: prioritize selective caching and object caching; dashboards and personalized content must remain dynamic.
• Hosting with managed caching: check how it works first. Do not add a second plugin that generates HTML without knowing how purging works.
• International audience: a CDN can reduce the distance from the origin. Edge HTML caching should only be enabled with verifiable bypass and invalidation rules.

Page cache, object cache, OPcache, browser cache, and CDN

These layers can coexist, but they solve different problems. Redis does not make a public page faster when it is already fully served by page cache; similarly, a CDN for images does not mean that WordPress HTML is stored at edge locations.

In WordPress, the standard object cache is normally limited to a single request. To make it persistent across requests, you need a backend such as Redis or Memcached and a wp-content/object-cache.php drop-in. Page cache often uses the wp-content/advanced-cache.php drop-in, a server cache, or a hosting reverse proxy. The WordPress documentation on caching describes the available mechanisms.

2. Map active layers and configure a simple flow

Before installing a plugin, check what your provider already offers. Many hosting services apply server-side caching through Varnish, Nginx FastCGI cache, or proprietary systems; adding a second HTML generator without understanding the order of operations makes it harder to invalidate the correct copy.

Check the hosting dashboard, plugins, and site configuration for:

• hosting page cache or reverse proxy;
• an active CDN and whether it includes edge HTML caching rather than static assets only;
• Redis or Memcached included with the plan;
• OPcache enabled on the server;
• active caching, CDN, and optimization plugins;
• the wp-content/advanced-cache.php and wp-content/object-cache.php files;
• which command or dashboard purges the plugin, hosting, and CDN caches.

The WP_CACHE constant in wp-config.php does not prove that page cache is working: it enables the early loading of a compatible solution, but does not create a cache on its own. Its role is documented in the WordPress guide to wp-config.php.

A common operational flow is: identify the hosting cache; choose the single primary handler for public HTML; configure exclusions for login, cart, checkout, and account pages; verify that purging also reaches the CDN if it stores HTML; then test the same URLs as an anonymous visitor, a guest with items in the cart, and an authenticated user. If a step cannot be verified, do not add another cache layer until the existing one is clear.

3. Configure page cache and CDN without serving personal content

Exclusions: URLs, cookies, query strings, and responses

A rule based only on the URL is not enough. A product page may be cacheable for an anonymous visitor, but the same request must not receive shared HTML when it contains a session, a cart, or personal information.

Exclusions should consider at least:

• sensitive URLs: login, cart, checkout, account, restricted areas, and admin endpoints;
• user state: authenticated users, users with a specific role, or HTTP authorization;
• login, session, and cart cookies;
• query strings that change content, such as search, filters, and personalization parameters;
• response headers and directives, including Cache-Control: private and Set-Cookie.

The presence of Set-Cookie does not automatically make a response uncacheable in every proxy or CDN. However, if the cookie represents an individual state, the response requires a bypass or explicit rules to prevent personal content from being shared. HTTP directives and cache behavior must be assessed together.

Browser cache and HTTP headers

HTTP headers determine how long a response can be reused. max-age specifies freshness for the client; s-maxage applies to shared caches such as proxies and CDNs. public indicates that a response can be shared, while private limits it to the user’s browser.

no-cache does not mean “do not store”: the response may be retained, but it must be revalidated before reuse. Use no-store to prevent storage. The stale-while-revalidate directive can temporarily allow the use of a stale response while it is being refreshed. For the meaning of these directives, see the MDN Cache-Control reference.

Avoid using the same duration for everything: stable, versioned assets can have long TTLs; HTML for updated pages often requires more cautious durations or reliable purging after publishing, price changes, and content edits.

CDN, edge HTML, and Cloudflare

A CDN can distribute images, CSS, JavaScript, and fonts without caching HTML. With Cloudflare, default behavior primarily concerns static resources; caching HTML pages requires dedicated rules or solutions such as APO. Cacheability depends on the request method, headers, cookies, response, and applied rules.

“Cache Everything” is not a setting to enable blindly: with cookies, query strings, or personalized pages, it requires explicit bypass rules and complete testing. The available conditions and rules are described in Cloudflare’s documentation on default cache behavior and Cache Rules.

4. WooCommerce and restricted areas: what must remain dynamic

An e-commerce site can achieve apparently good response times and still be configured incorrectly. The cart, checkout, My Account, login, password recovery, dashboards, and role-dependent content must not be served as shared HTML.

In addition to URLs, make sure the cache recognizes relevant WooCommerce cookies such as woocommerce_cart_hash, woocommerce_items_in_cart, and the session cookie with the wp_woocommerce_session_ prefix. Plugins, payment gateways, consent tools, and additional functionality may introduce further cookies that need to be assessed. WooCommerce provides practical guidance in its guide to configuring caching plugins.

Before going live, perform at least the following test, both in an incognito window and as an authenticated user:

1. add a product as a guest and check the cart counter;
2. open the cart, change the quantity, and remove an item;
3. proceed to checkout;
4. test login, account access, and password recovery;
5. change a price, availability, or promotion and verify the result in an anonymous window.

An empty cart after adding an item, outdated prices, inconsistent sessions, or abnormal login behavior require you to check bypasses and exclusions before addressing performance metrics.

5. Verify cache, HIT/MISS, and invalidation

Before changing the configuration, record a baseline for the homepage, post, archive, product, cart, checkout, and account pages. For each URL, note the visitor state: anonymous, with cookies, and authenticated. Measure TTFB, HTTP headers, and functional behavior; if the provider exposes them, retain application or query timings as well.

Check headers with curl and DevTools

On a public page, repeat the same request two or three times without cookies:

curl -sD - -o /dev/null -H "Accept: text/html" https://www.esempio.it/pagina/

Review Cache-Control, Age, ETag, Last-Modified, CF-Cache-Status, and any proprietary hosting headers. If the HTML is actually eligible for Cloudflare caching and the request does not vary by cookie, query string, cache key, or header, an initial MISS followed by a HIT, with increasing Age, is consistent with a response served from the edge.

CF-Cache-Status: DYNAMIC indicates that Cloudflare did not consider that response cacheable. BYPASS does not, by itself, identify an error: it must be interpreted according to the response directives and applied rules. Cloudflare documents statuses and causes of uncacheable responses in its guide to investigating uncached responses.

To simulate a request with cookies, use a test cookie without copying real session cookies into scripts or documentation:

curl -sD - -o /dev/null -H "Accept: text/html" -b "nome_cookie=valore_di_test" https://www.esempio.it/pagina/

curl does not replicate browser caching or every header sent by a browser. Complete the check in DevTools, in the Network tab: inspect the HTML response, any redirects, headers, cookies that are set, and the value of Vary. The Chrome DevTools Network documentation explains how to inspect requests.

Test purging with a real change

Temporarily add a unique text marker to a public page, publish the change, and check the result in an anonymous window. If the site uses a CDN or has an international audience, repeat the test from a second network or location when possible.

The test must confirm normal invalidation between WordPress, the hosting cache, and the CDN. Do not start with “Purge Everything”: if clearing everything is the only way to see an edit, the invalidation flow needs to be fixed.

6. When content remains stale or performance does not improve

Stale HTML, an outdated PHP file, and old application data have different causes. For HTML, follow this order: browser, page caching plugin, server cache or reverse proxy, then CDN. If a PHP code change does not appear, check OPcache and the deployment process: opcache.validate_timestamps and opcache.revalidate_freq affect the detection of modified files. Resetting and restarting depend on the permissions available and how hosting is managed. Consult the PHP OPcache documentation before changing these settings.

If the issue involves transients, application values, or query results, object cache is a more likely candidate. Do not clear all layers indiscriminately: isolate the responsible one first.

Redis may not produce a visible improvement in PageSpeed because it primarily helps dynamic requests, the admin area, and authenticated users; an effective page cache can avoid PHP and database work for anonymous traffic. Site Health may detect a persistent object cache, but it does not demonstrate hit rate, sizing, or real benefit. Measure before and after on the requests that actually use it.

PageSpeed Insights combines lab data and real-world CrUX data; the latter covers a rolling 28-day window and may be unavailable for URLs with low traffic. Better TTFB does not automatically solve heavy images, JavaScript, fonts, CLS, INP, or third-party scripts. First verify caching, headers, and dynamic flows; then use Lighthouse or PageSpeed to identify the next bottleneck.

As a final check, confirm that public pages receive the intended cache behavior, personal requests are excluded from shared cache, a published change reaches every copy, and WooCommerce or authenticated areas work correctly. Only then does it make sense to add object caching or edge caching as targeted optimizations.