Question: Why does Google PageSpeed show a 95 for my homepage, but as soon as customers add something to the cart, performance completely collapses?

Answer:

Because PageSpeed measures a different performance situation than the one your customers enter after they interact with the shop.

A homepage score of 95 usually reflects how well a mostly static, cacheable page performs under controlled lab conditions: a simulated device, a clean browser, no cart, no session, no customer state and often a cached main document.

That can be useful, but it is not the same as measuring a real WooCommerce cart request.

As soon as a customer adds something to the cart, WooCommerce has to deal with dynamic state. The request may involve session handling, cart contents, cart fragments, dynamic pricing, shipping logic, tax logic, coupons, stock checks, payment-related preparation and customer-specific conditions.

In that situation, full-page caching usually cannot behave like it does on the public homepage. WordPress has to execute PHP again for the individual customer context.

That is why the PageSpeed score did not predict the collapse. It mainly evaluated the optimized output of a cacheable page. It did not measure how much WordPress and WooCommerce have to execute when the cart becomes dynamic.

The central limitation is this:

PageSpeed can reward optimized output while ignoring the execution cost of real shop interactions.

Cart and checkout requests are exactly the requests where this distinction matters most. They are dynamic, commercially critical and often difficult or impossible to serve as simple cached documents.

On a typical WooCommerce site, WooCommerce is also not alone. SEO plugins, page builders, form plugins, analytics tools, marketing integrations, membership extensions, translation plugins, sliders, review tools, tracking scripts and many other plugins may still become part of the WordPress runtime.

Some of those plugins may be required for the cart. Many may not be.

Classic optimization still matters. Better hosting, object cache, database tuning, fewer frontend assets, smaller JavaScript payloads, optimized images and cleaner plugin choices can all help. But they do not fully solve the deeper execution problem:

When the cart bypasses the page cache, WordPress may still load the full plugin stack for a request that only needs a smaller subset.

So the collapse after adding a product to the cart is not a contradiction. It is the difference between a cache-friendly homepage and a dynamic WooCommerce application request.

Can WordPress prevent unrelated plugins from loading during cart and checkout requests?

Not by default.

WordPress normally treats active plugins as part of the global runtime. Once a request enters the normal WordPress bootstrap, the site usually prepares the same active plugin environment before the request-specific logic can do its work.

That is why many optimization tools can improve how the homepage is delivered, how assets are loaded, how objects are cached or how frontend output is measured, while still not preventing unrelated plugins from entering a dynamic cart request in the first place.

For cart and checkout performance, the relevant question is not only:

How can the generated page be optimized?

The more structural question is:

Which plugins should be allowed to execute for this cart or checkout request at all?

This is where Performance by Prevention becomes relevant. The goal is not merely to make the full WordPress plugin stack execute faster after the cache has been bypassed. The goal is to prevent unrelated plugin execution before the main document is generated.

LiteCache Rush applies this principle to WordPress. It determines the request context early and controls which plugins are allowed to load before the normal WordPress bootstrap continues.

For WooCommerce, that means cart and checkout requests can keep WooCommerce and required shop-related plugins, while unrelated functionality such as sliders, contact forms, gallery tools, frontend-only widgets or marketing extras do not have to enter that request if they are not needed.

That is the practical distinction:

PageSpeed can make a cached homepage look excellent. Performance by Prevention reduces what the server has to execute when the customer actually shops.

So the structural fix is not only to chase a better homepage score. It is to reduce unnecessary plugin execution in the dynamic WooCommerce requests where revenue is actually decided.