Question: I have Redis Object Cache activated on my server, but the WooCommerce cart doesn't feel any faster at all. Why is that?

Answer:

Because Redis Object Cache solves a different problem than the one slowing down your WooCommerce cart.

Redis is a database/object cache. It stores certain query results and object data in memory so WordPress does not have to ask MySQL for the same information repeatedly. That is useful, especially on busy WordPress sites.

But the WooCommerce cart is not mainly a repeated database lookup problem. It is a dynamic, session-specific execution problem.

Every cart request still has to start WordPress, load active plugins, initialize WooCommerce, read the current visitor session, calculate cart contents, check prices, taxes, shipping rules, coupons, stock state, payment-related logic and whatever other plugins attach themselves to WooCommerce hooks.

Redis can make some database-related parts faster after WordPress is already running. It cannot prevent WordPress and the plugin stack from running in the first place.

That distinction matters because a cart is unique to one visitor and one session. Your cart is not my cart. A cart request often cannot be treated like a public page where the same generated result can simply be reused for everyone.

So Redis may improve the site in general, and it may reduce some repeated database work. But if the slow part is the amount of PHP, WordPress and plugin code that executes around the cart request, Redis does not remove that work.

Redis can make some lookups faster. It does not decide which plugins should be allowed to run for a cart request.

That is why a WooCommerce cart can still feel slow even when object caching is active. The bottleneck may not be the database lookup itself. The bottleneck may be the full execution stack that still surrounds every dynamic cart interaction.

Can the unnecessary plugin execution around WooCommerce cart requests be prevented?

Not by Redis, and not by normal page caching.

To prevent that overhead, the decision has to happen earlier: before the normal WordPress bootstrap continues and before unrelated plugins are loaded into the request. At that point, the system needs to recognize that the current request belongs to a WooCommerce cart context and allow only the plugins required for that context.

This is the execution-layer problem that Performance by Prevention addresses.

LiteCache Rush applies this principle to WordPress. Instead of trying to make the fully loaded cart request faster after everything has already entered the runtime, Rush controls plugin loading earlier and prevents unrelated plugins from executing for that request type.

For a WooCommerce cart, that can mean allowing WooCommerce, required payment/session/shipping logic and other truly relevant components, while preventing unrelated sliders, forms, marketing tools, page-builder extras, analytics add-ons or frontend-only plugins from loading into the cart request.

Redis makes parts of the database layer faster.

LiteCache Rush reduces unnecessary execution before the cart response is generated.

So the answer is not that Redis is useless. Redis is solving a real problem. It is simply not the same problem that often makes WooCommerce cart requests slow.