Cart and Checkout Performance: What Should Never Be Cached

This article assumes something is already wrong: a poor PageSpeed Insights result, a GTmetrix waterfall that looks noisy, a WordPress admin warning, a checkout complaint or a DNS change that has not landed cleanly.

Use PageSpeed Insights for Core Web Vitals clues, GTmetrix for request order, Chrome DevTools for browser behaviour and WordPress admin screens for the settings or plugins that changed.

The first investigation should end with a decision, not a pile of screenshots. Decide whether the next step belongs to WordPress content, theme output, plugin assets, LiteSpeed Cache, BunnyCDN, DNS, SSL, database work or hosting resources.

Checkout must stay dynamic

A WooCommerce problem around WooCommerce checkout caching must separate cached catalogue browsing from dynamic purchasing. Product pages, baskets, checkout and accounts are not the same workload.

• category pages are fast but checkout waits
• cart fragments run on pages that do not need them
• variation data inflates product page HTML
• scheduled actions or sessions grow quickly

For WooCommerce, do not use one test page as proof. Product browsing, basket updates, checkout, account pages and order emails exercise different code paths and different cache rules.

Testing payment and shipping steps

Use the tools for different questions rather than running them all and hoping one gives a simple answer.

• WooCommerce Status screen
• GTmetrix waterfall for product and checkout pages
• LiteSpeed Cache exclusions
• Query Monitor
• test order flow

Cache exclusions that protect customers

• 1. exclude cart, checkout, account and order-pay from shared cache
• 2. measure product, category and checkout pages separately
• 3. review payment, shipping and recommendation scripts
• 4. optimise product images before CDN delivery

A store needs two test plans: one for catalogue browsing and another for buying. Category and product pages can usually benefit from shared cache; basket, checkout, account and order-pay pages must remain dynamic and customer-specific.

Decision point for WooCommerce checkout caching

For WooCommerce checkout caching, decide whether the page is catalogue, basket, checkout, account or admin. Catalogue pages can often be cached and delivered efficiently. Checkout and account pages must stay dynamic. Cart fragments, payment scripts, shipping APIs and scheduled actions need their own test path.

Keep a small change log beside the work. Record the previous value, the new value, the cache purge performed and the exact URL retested. That makes rollback possible when a later plugin update changes the behaviour.

Artefacts to keep for WooCommerce checkout caching

Keep the proof close to the change. If a setting is adjusted, capture the previous state, the new state and the test result that justified it.

• WooCommerce Status screenshot and active payment/shipping plugins.
• Network trace for product, basket and checkout pages tested separately.
• LiteSpeed exclusions for cart, checkout, account and order-pay URLs.

Checkout mistakes

• caching customer-specific pages
• testing only as an administrator
• adding product widgets without checking INP

If the result changes by login state, treat that as evidence. Public cache, private sessions, WooCommerce fragments and administrator scripts can all show different behaviour on the same URL.

Final validation pass

• Run product, basket, checkout and account tests separately.
• Confirm cart and checkout pages are excluded from shared cache.
• Place a test order after payment, shipping or cache changes.

Questions about checkout speed

What makes WooCommerce checkout caching different on WooCommerce?

Shared cache should not serve customer-specific WooCommerce pages. Cart, checkout, account and order-pay URLs need exclusions, then a real test order should confirm totals, shipping, payment and emails.

Can checkout be cached?

Shared cache should not serve customer-specific WooCommerce pages. Cart, checkout, account and order-pay URLs need exclusions, then a real test order should confirm totals, shipping, payment and emails.

Which page should be tested first?

WooCommerce checkout caching should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

If the fix improves one metric and damages another, keep investigating. A faster LCP is not a win if checkout breaks, CLS jumps or the mobile menu stops responding.

For WooCommerce, add the customer state. Logged-out browsing, customer with basket, logged-in account user and administrator are different tests. Cache headers that are correct for a category page may be dangerous on checkout.

If the store has many orders, check scheduled actions and sessions before blaming the theme. Checkout delays often come from dynamic work that never appears on a cached product page.

Also check ownership of checkout scripts. Payment, finance, shipping, reviews and analytics scripts should all have a reason to run during purchase. Remove anything that does not support the transaction.

Do this before changing production settings, not afterwards.

Record the result so the next reviewer can understand the change.

Do not swap test pages mid-investigation; it makes improvement impossible to prove.

Ambiguous results usually mean the diagnostic step was too broad, not that more toggles are needed.

Before production changes, know which backup, export or previous value gets you back.

When the issue involves Core Web Vitals, record which metric you are trying to move before changing settings. LCP, INP and CLS often need different fixes, so one combined score is not enough evidence.

Save the note with the test result so the next fix starts from evidence, not memory.

Summary

A good fix leaves the site easier to support. The cache rules are known, the CDN behaviour is verified, the WordPress setting is documented and rollback is possible if the next update changes the result.