Question: As soon as customers log into my WooCommerce shop or access their account ('My Account'), the page becomes extremely slow. My caching plugin understandably deactivates itself for logged-in users. How do I optimize performance specifically for these sessions when normal caching isn't possible?

Answer:

Your caching plugin is behaving correctly - and that is exactly where the performance problem becomes visible.

Logged-in WooCommerce users receive personalized content. Their account page may show order history, saved addresses, downloads, subscriptions, memberships, payment methods, session state and customer-specific notices. Serving one cached account page to another logged-in customer would be unsafe, which is why serious page caching systems exclude authenticated sessions by default.

That exclusion is not a configuration error. It is a necessary architectural boundary.

But the consequence is significant: every logged-in customer accessing My Account triggers a full dynamic WordPress request. No full-page cache safely intercepts it. No CDN can simply replace it with a static document. The request reaches the origin server, and WordPress has to generate the response for that specific customer.

On a typical WooCommerce installation, that does not only mean WooCommerce account logic. It often also means that the complete active plugin stack is loaded around that request, even when many of those plugins have no direct role in showing account data.

For example, the request may still load:

• page builder components
• slider plugins
• contact form plugins
• SEO plugins
• cookie banner logic
• analytics integrations
• marketing and tracking tools
• homepage widgets
• frontend-only extensions
• unrelated shop add-ons

Some of those plugins may be useful elsewhere on the site. That does not mean they are useful during a logged-in account request.

This is the structural reality that caching cannot address directly. Page caching avoids repeated execution for identical public responses. Logged-in account sessions are not identical enough to cache safely, so the server still has to execute WordPress for each request.

The deeper performance question is therefore not only:

How can this account page be cached?

The more important question is:

How much unrelated WordPress and plugin code should be allowed to execute during this logged-in account request?

Classic optimization still matters. Database cleanup, object cache, fewer WooCommerce add-ons, faster hosting, optimized payment plugins, reduced Action Scheduler overhead and careful profiling can all help.

But they do not remove the underlying execution pattern:

A logged-in WooCommerce account request may still load far more plugins than it actually needs.

That is why these sessions often become slow exactly where page caching stops helping. The bottleneck is not only personalized content. It is personalized content surrounded by unnecessary global plugin execution.

Can logged-in WooCommerce sessions be optimized without unsafe page caching?

Yes, but the optimization has to happen at a different layer.

If an account page cannot be safely served as a shared cached document, the practical alternative is to make the dynamic request itself lighter. That means reducing what WordPress is allowed to load and execute for that specific account context.

This is where Performance by Prevention becomes relevant.

Instead of trying to cache a logged-in account response that should remain personalized, the prevention approach asks:

Which plugins are actually required for this logged-in WooCommerce account request?

The practical implementation discussed in this FAQ is LiteCache Rush. Rush controls plugin loading before the normal WordPress bootstrap continues. For a My Account request, Rush can allow WooCommerce, session handling, account-related extensions and required membership or payment logic, while unrelated plugins are prevented from entering that request at all.

That distinction matters:

Caching tries to avoid generating the response again.

Performance by Prevention reduces the work required when the response must be generated dynamically.

For logged-in WooCommerce users, that is often the decisive layer. The server does less work per request not because the account page was cached, but because unnecessary work was prevented before it started.

Where full-page caching has to step aside for authenticated sessions, execution prevention becomes the structural optimization path.