WooCommerce Speed Test: How to Test Cart, Checkout and Logged-In Pages

A fast WooCommerce homepage does not mean a fast store. Shoppers judge your store on the pages where money changes hands: the product page, the cart, checkout, and the account pages they use after logging in. This guide shows how to run a proper WooCommerce speed test, what to measure on each step, and how to read the results without being misled by a single homepage score.

If you only test the homepage, you are usually testing the easiest page on the site. A proper test follows a real shopper: find a product, add it to the cart, review the cart, start checkout, and check the account area. That journey is where slow queries, uncached pages, cart fragments, and payment scripts show up.

Why homepage scores mislead

A homepage test is often a cached, anonymous visit. The page can be served from full-page cache, the visitor has no cart, no login session, and no personalised content to build. Cart, checkout, and logged-in pages are different by design: they must be dynamic, so they cannot be cached in the same way.

That difference explains why a store can look excellent on a homepage test and still feel slow where it matters. On a dynamic page, WordPress and WooCommerce have to check the session, load the cart, calculate totals, check stock and shipping, and render account-specific content. A slow database query or a heavy plugin that never touches the homepage can dominate checkout, while remaining invisible in a homepage score.

• Cached versus dynamic: a cached anonymous homepage may skip much of the work that cart and checkout must do on every visit.
• Cache exclusions: cart, checkout, and account pages are normally excluded from page caching, so they reveal server and database performance more honestly. See the WooCommerce cache exclusions guide for which pages and cookies should stay uncached.
• Cart fragments: mini-cart updates can trigger extra requests on many pages, especially when fragments are refreshed unnecessarily.
• Payment and gateway calls: checkout loads payment methods, address and shipping logic, and third-party gateway scripts. A gateway that is slow, blocked, or misconfigured can delay checkout even when the rest of the site is fast.
• Logged-in overhead: logged-in shoppers bypass page cache, may see more plugins and admin-bar-related work, and trigger personalised queries that an anonymous test never sees.

The lesson is not that homepage testing is useless. It is useful as a baseline. It is simply not a WooCommerce speed test on its own. For a fuller picture, start with the WooCommerce speed optimization complete guide, then test the buying journey itself.

How to test WooCommerce properly

A useful test is repeatable, comparable, and tied to a real journey. Before you change anything, decide what you will test, how you will test it, and what you will record, so a later test can be compared fairly.

• Test logged-out and logged-in separately. Run the same journey as a guest, then as a logged-in customer. Record which session you used for each run, because the results are not interchangeable.
• Use a test product. Create a simple, low-priced test product that is clearly marked for testing, so you do not disturb real stock or real orders.
• Cover every step: product page, cart page, checkout page, and account pages such as orders and addresses. Also test add to cart and variation changes, because those interactions matter as much as initial page load.
• Repeat runs. Run each page more than once and look for a pattern, not a single outlier. One slow run can be a cold cache, a busy server moment, or a third-party delay.
• Keep conditions the same. Use the same device type, connection profile, test location, and browser conditions when you compare before and after a change. Changing several conditions at once makes the comparison meaningless.
• Note the tool you used. Record whether you used PageSpeed Insights, GTmetrix, WebPageTest, or another tool, and which settings you chose. Different tools measure different things, so a score from one tool is not directly comparable to a score from another. The best WordPress speed test tools guide explains what each kind of tool is good for.

Also record the basics for every run: the page tested, the session type, the device and connection, the date, and the change you were testing. Without that note, you will not know later whether an improvement came from your fix or from a different test setup.

How to script cart and checkout tests

Single-page tests cannot follow a shopper through a cart. WebPageTest can script a multi-step journey, which makes it especially useful for a WooCommerce speed test. You do not need to publish a script or claim a particular result to use the method: describe the journey, keep the test data safe, and record what happens at each step.

1. Start on a product page. Script a visit to a test product, not just the homepage, so the test includes product, variation, and add-to-cart work.
2. Add the test product to the cart. Script the add-to-cart action and wait for the cart confirmation or mini-cart update before moving on.
3. Open the cart page. Record cart load, quantity updates, and any fragment refreshes that happen on that page.
4. Go to checkout. Script the move to checkout and wait for the form, shipping options, and payment methods to become usable, not merely visible.
5. Fill checkout with test data only. Use clearly fake test details for name, address, and contact fields, and stop before any real payment step.
6. Watch the whole journey, not just the final page. Note where the flow stalls: product load, add to cart, cart refresh, checkout load, shipping calculation, or payment-method rendering. Each stall points to a different cause.

Keep test data and payments safe. Run scripted checkout tests on staging, or on a store that is in a test or sandbox payment mode with test credentials. Never run a real payment test on a live store, never use a real card for a test order, and delete or cancel test orders and test accounts when you are finished so they do not pollute reports or stock.

If checkout is slow in a scripted test, do not guess at the cause. Use profiling to see what is actually slow. The Query Monitor tutorial shows how to find slow queries, hooks, and plugins, which is often the fastest way to separate a server problem from a plugin or gateway problem.

Which metrics matter on checkout

Checkout is not a brochure page. A shopper needs the form to load, respond, and complete without errors. Judge checkout on whether each interaction works promptly, not on whether a single aggregate score looks impressive.

• Server response: how quickly the server starts responding for cart and checkout. A slow server response delays everything that follows, including payment and shipping logic.
• Largest Contentful Paint (LCP): how quickly the main checkout content becomes visible. A late LCP often points to slow server work, render-blocking resources, or a heavy checkout layout.
• Interaction to Next Paint (INP): how responsive the page feels when a shopper clicks, changes a variation, updates a quantity, or selects a shipping or payment option. Slow INP is especially damaging on checkout, where every hesitation feels like a risk. See the WooCommerce INP guide for slow add-to-cart and interaction problems.
• Cumulative Layout Shift (CLS): whether the checkout form jumps as payment methods, shipping options, or banners load. Shifts cause mis-clicks and abandoned checkouts, even when load times look acceptable.
• Time to interactive elements: when the shopper can actually use the key controls: quantity controls, shipping choices, address fields, and the place-order control. A page that looks loaded but does not respond is not fast.
• Error and completion checks: whether the journey completes cleanly in the test. Record failed fragment updates, shipping or payment errors, console errors, and any step where the shopper would have to reload or start again.

For the wider Core Web Vitals picture, the WordPress Core Web Vitals guide explains LCP, INP, and CLS in context. On checkout, apply those same ideas to interactions, not just to first paint.

Which vanity numbers to ignore

• A single homepage score, presented as if it describes the whole store.
• A one-off fast run, with no repeat runs and no note of the test conditions.
• Total page weight alone, without knowing whether the weight is on checkout or on a page shoppers rarely use.
• A lab score that improves while real shoppers still report slow add to cart, slow shipping calculation, or payment errors.

When a number improves but the journey does not, trust the journey. Re-test the same cart-to-checkout flow under the same conditions, and check whether the specific stall you found has actually gone.

What to record for every test

• Page and journey step tested, and whether the session was logged-out or logged-in.
• Tool used, test location, device type, and connection profile.
• Server response, LCP, INP, and CLS for checkout, plus time to interactive elements.
• Errors, failed updates, and whether the journey completed.
• What changed since the last test, so improvements can be attributed honestly.

That simple record turns a WooCommerce speed test from a screenshot into a diagnosis. It also makes it much easier to ask for help, because a developer can see exactly which step is slow, under which conditions, and what has already been tried.

Next step

If your homepage looks fast but cart or checkout still feels slow, test the full journey first, then fix the step that actually stalls. If you would like expert help with that diagnosis, request a free speed audit from ProSpeedGuy and share your cart-to-checkout test notes, including which pages were slow and whether you tested logged-out, logged-in, or both.

Common Questions

Frequently Asked Questions

Clear, honest answers about testing cart, checkout, and logged-in pages.