WooCommerce cart not loading: what stalls

Adding an item sends a request to the store, and the cart page then asks for the cart again. The store may answer slowly, answer with an error the page does not show, or hand back a copy of the cart that a cache kept from an earlier visit. Scripts from the theme and from plugins also run on the cart page, and one that throws an error can stop the cart from drawing even when the data arrived. From the shopper's side all of these look the same: a spinner, then nothing. The record of requests tells them apart.

• Add one item from a product page in a private window. Does the cart count change, or does a spinner stay?
• Open the cart from the header link, then from the menu. Does it stall both ways?
• In WooCommerce's page settings, check which page is set as the cart. Does that page hold the cart block or shortcode?
• Look for a cache rule that covers the cart and checkout pages. Those pages should not be served from cache.
• In the Mimiq report, open the cart step. Is there a failed request or a script error on it?

A spinner in the small cart panel usually means the add request did not come back. The page asked the store to add the lamp, the store did not answer, and the panel waits. Opening the full cart then sends a second request, which may work, so the shopper sees the panel stuck and the cart page fine. That split is worth noticing, because it points at the add request, not at the cart page itself.

A full cart page that never paints is a different fault. The cart page setting in WooCommerce chooses which page shows the cart. If that page holds the wrong content, or a block that does not draw the cart, the shopper sees text and no cart. If the page holds the right cart but a script waits on a request, the shopper sees a spinner that outlives the page. Check the setting first, then the requests, because the setting is the one fix that takes a minute.

A page cache keeps a copy of a page so the next visitor gets it fast. That is a good trade for a blog post and a bad one for a cart, because the cart shows what this shopper has put in it. A cached cart can show a count from an earlier visit, or a spinner that was saved in the copy. WooCommerce pages for the cart and checkout are normally left out of a page cache, so the cache rule for them is the first thing to check.

The right version is a cache that serves the shop and product pages normally and skips the cart and checkout entirely. The wrong version is one rule that caches every page on the site, which often passes a simple check on the home page and fails only when a shopper adds something. Test the cart after any change to the cache, even if nothing on the cart page was touched.

Give Mimiq the shop address and one task a shopper would have: put a desk lamp in the cart and open it to see the total. Each simulated visitor arrives from a search as a stranger, which is how a shopper meets a store for the first time. The report shows the step where the count did or did not change, the screenshot of the cart on that step, and every request that never finished or ran too long.

A visitor test does not reproduce every shopper. It cannot show what happens on a slow mobile network or on an old phone, and a stall that only appears there needs a check on a real device. It does show whether a new shopper reaches a working cart, and whether the add request and the cart page each finished, so you know which one to fix.

Rerun the same visitor task after every plugin update, theme change or cache setting change, and before any sale that sends traffic to the cart. A caching plugin that is updated or reconfigured can start serving the cart page again, and the spinner comes back with no change to the code. Use the same task each time, so the results can be compared from one run to the next.