Cache WordPress: speed up without mixing carts or blocking forms

9 min read

An efficient WordPress cache reuses public content without reusing visitor-specific data. An old price, a basket that seems empty or a rejected form cannot necessarily be corrected by emptying everything. You need to identify the response involved, the layer that maintains it, and the conditions under which it varies.

The correct setting is not “cache everything”. It consists of keeping what can be shared, isolating sessions and planning a purge after modification. Validation concerns the content received and the possible actions, not just the display speed.

Identify what each layer keeps

Four layers can occur on the same visit. Distinguishing them avoids asking an extension to correct a problem that it does not control.

• Browser : It keeps responses locally, including files and sometimes HTML. This cache belongs to the client, unlike a cache shared between visitors.^[11]
• Page : an extension where the server keeps a HTML response already produced. If it contains a first name or a basket, its reuse must be controlled.
• Subject : The application reuses intermediate data, rather than the entire page. Find out which objects are stored, with which keys and which invalidation. Do not assume that a visual defect comes from this layer.
• CDN : a service in front of hosting can keep responses independently of the page cache. A purge in WordPress does not prove that this copy is gone.

Note the active extension, the host options, the possible CDN and the persistent object cache. For each layer, identify who sets the exclusions and who triggers the purge. Do not overlap two page mattes without knowing how they fit together.

Cache WordPress: read the directives without contradiction

Three HTTP directives meet different needs:

• no-cache allows storage, but requires revalidation before reuse by cache HTTP. It does not mean “no copies”.^[11]
• no-store asks not to store the response. However, it does not delete old responses already kept for this URL: a correction must also process these copies.^[11]
• private reserves storage for private caches, notably for the browser. It is neither encryption nor account access control.^[11]

For a personalized response that needs to be revalidated, Cache-Control: no-cache, private is a schema documented by MDN.^[11] Reserve no storage for responses that your policy requires not to be retained.

A managed cache can follow its own rules: control the documentation and behavior of the CDN or server, not just Cache-Control.^[11] Finally, a cookie does not automatically make a response private.^[11]

Exclude dynamic routes and master sessions

WooCommerce asks to exclude the shopping cart, order validation and customer account from the cache, because these pages display information specific to the visitor.^[10] Check the configured URLs, their language variants, and account steps. A rule aimed only /cart/ is insufficient if your cart uses another address.

Our approach then consists of tracing the variations: connection, active basket, currency or pricing according to the profile, if these functions exist. For shared HTML, favor a workaround when the session customizes the response. A finer variation requires documented keys and a acceptance testing demonstrating insulation.

Cookies woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_ are among the signals described by WooCommerce.^[10] Configure their processing following integration; don't remove them to artificially increase responses served from cache.

The exclusion of _wc_session_ is also mentioned for systems offering a database cache, depending on the extension or hosting.^[10] This conditional advice does not justify disabling any object cache.

Also control the mini-basket integrated into public pages. If this block is renewed separately, check the response that feeds it in both profiles: a correctly excluded page does not protect a custom fragment stored elsewhere.

Diagnostic table by layer and user scenario

Here is a work grid, not a list of observed incidents. Symptoms are diagnostic scenarios; the evidence indicates what your acceptance testing should establish.

Check in order and keep proof of validation

Before any modification, prepare a acceptance testing sheet: URL, scenario, connection state, expected content, active layers and planned change. Use test accounts and fictitious contact details. Note the names of useful cookies, never their values ​​or tokens in a shared document.

1. Establish reference. Check the saved data and behavior without reuse by the affected caches. On a protected pre-production, test the dynamic path first, then activate the layers separately. A staging with different cache rules does not validate production.
2. Track reply. Examine the browser, then the CDN, the page cache, and finally the objects if necessary. Note the available headers and provider flags. The absence of an indicator does not prove the absence of a cache.
3. Decide and purge. Fix the identified layer, purge the affected URLs and check the variants. Also organize the invalidation after a change in price, content or configuration; do not rely solely on manual bleeding.
4. Prove insulation. Open two separate browser profiles, A and B. Add different articles, navigate to the account, and submit the allowed forms. Two tabs from the same profile do not constitute two isolated sessions. Then repeat these steps after reusing the cache, then after disconnecting. A successful test immediately after purge does not verify all retained responses.

Archive the retained configuration, the redacted captures, the relevant responses and the acceptance decision. Do not validate if data passes from one session to another, even when the loading appears better.

Fictitious case: old price, baskets still distinct

In this explicitly fictitious case, a store displays an old price on a product pages, while the basket must remain specific to each visitor. Start by checking the recorded price and the public response: an outdated copy HTML is not a session error.

If the public record is the stale copy, target its invalidation in the page cache and CDN. If the price varies by account, treat this variation as custom, without posting its response to a common cache.

The expected validation combines two observations: the form presents the reference price and baskets A and B remain distinct after browsing and returning to the form. A corrected price is not enough to accept the configuration.

Forms: separate display, sending and personal data

For each form, identify the display page, the sending destination, any tokens and pre-filled data. Our acceptance testing rule is to test the display, the sending, the confirmation message and a new attempt after navigation. The public HTML and the custom response should not automatically receive the same policy.

If the extension generates a token depending on the session or its validity period, check its renewal mechanism. In the absence of documented compatibility, bypass the page cache on this route; do not remove the protection to make the form usable. Exclude send responses that contain personal data or session state from the shared cache.

These settings do not demonstrate GDPR compliance: they check neither the legal basis of the form nor its retention policy. Once the functional acceptance testing has been validated, our Core Web Vitals guide helps distinguish loading, interactivity, and stability before other fixes.

Frequently asked questions

Why does password reset go back to login?

WooCommerce reports that a cached account page can cause this loop, especially if the server cache does not exclude it.^[10] Ask the host for verification, then retest the link with a fictitious account, without a session already connected. Include the reset steps in the account journey exclusion, not just its main screen.

Can we keep CSS files cached on the customer account?

Yes, immutable static files are particularly suitable for caching.^[11] The account's HTML and its public resources do not have the same policy. Verify that the file remains the same for everyone and does not contain any session data. When a file changes, control its versioning or invalidation, without indiscriminately disabling the cache of all elements.

Should everything be purged after a product modification?

Not systematically. List the pages that include the modified data: file, category, search or block of recommendations, depending on your site. A targeted purge is relevant if these dependencies are known and covered by the integration. If they are not, choose a larger documented purge, then redo the acceptance testing; don't assume that only the plug changes.

Your next action: formalize a acceptance testing

Choose a product pages, the basket and a test form. Complete the grid, identify the person responsible for each layer and require proof of insulation before maintaining a setting. If the rules for hosting, CDN and WordPress overlap, the web services of 4SYSTEM can help you frame the diagnosis and validation.

Sources

• How to configure caching plugins for WooCommerce | WooCommerce developer docs (accessed 2026-10-08)
• HTTP caching - HTTP | MDN (accessed 2026-10-08)