WooCommerce checkout speed: a lighter, faster purchase

Why the checkout is different

On the rest of a store, a page cache does most of the work. The checkout is the exception. WooCommerce defines the constants DONOTCACHEPAGE, DONOTCACHEOBJECT and DONOTCACHEDB on the cart, checkout and account pages, and adds WordPress's no-cache headers. The reason is sound: the page holds the customer's basket, address and totals.

That means each checkout view is built by PHP, with database queries, on your server. A slow host, a missing object cache or a heavy plugin shows up here first. See WooCommerce speed for the whole store.

The page also loads its own scripts. WooCommerce adds a checkout script on this page only, and a payment tool, a tax or shipping plugin, an address lookup, analytics and sometimes a chat widget add more.

What happens when a visitor fills in the form

This is how the classic checkout script behaves, according to its source code:

• When the page loads, the script immediately asks the server for the order review. A checkout therefore makes at least two requests to your server before the visitor does anything: the page itself and this one.
• When the visitor changes a shipping method, a country or state, or the box that ships to a different address, the script asks the server to recalculate the order.
• When the visitor types in an address field, the script waits until typing pauses for one second, then asks, once the required address fields are filled in. If an address autocomplete tool is active, it waits until the visitor leaves the field instead.
• The request is update_order_review. It carries the form's values, and the server sends back the new totals, shipping and payment sections. The order review area is blocked with an overlay until the answer arrives.

So every recalculation is a full request to your server that loads WordPress and your plugins. If a shipping or tax plugin calls another company's server on each recalculation, the visitor waits for that too. A slow answer is visible, and it happens in the middle of a purchase.

To see it for yourself, open DevTools, go to the Network panel, type wc-ajax in the filter, and reload the checkout. The first request appears on its own. Then change a country and look at the time each request takes.

What slows a checkout

The server. The checkout is never cached, so the server's response time and the database matter. See hosting for WordPress and WordPress caching, where the object cache is covered.

Payment tools and other scripts. The 2025 Web Almanac describes payments as a major dependency surface: third-party scripts, redirects, fraud tools and compliance requirements. Each payment method that adds a button or a form field can load its own scripts. Wallet buttons, card fields, address lookups, tracking tags, session recording and chat all run on the main thread while the customer tries to type. See third-party scripts.

Too many fields. Every field is more typing, more validation and, for address fields, another recalculation.

Heavy page furniture. A large header, a slider, a newsletter pop-up or a related-products block adds weight to the page where the customer has least patience for it.

Slow rules. Complicated shipping, tax or discount rules take longer to calculate. This matters most for stores with many shipping zones or rules that call outside services.

What to fix

1. Make the server fast for pages that are not cached

Work through the host, PHP, the object cache and the plugins, as in the earlier guides. If the checkout is slow and the product pages are fast, this is the first place to look.

2. Remove fields you do not need

WooCommerce lets a developer change the checkout fields with the woocommerce_checkout_fields filter, and it has a separate filter and setting for the order notes box. Guest checkout is a setting too: if you require an account, the customer has more to do. Keep every field you need for shipping, tax and the law, and drop the rest. Test with real orders before you remove a field that a plugin or your fulfilment process relies on.

3. Load fewer scripts

• Run the audit on the checkout and open the 3rd parties insight. Match each entry to a tool you still need.
• Offer the payment methods your customers use, not every method available.
• Keep chat widgets and pop-ups off the checkout, or load them after the order is placed.
• Remove tracking tags that no longer feed a report.
• Do not delay payment scripts with a general "delay JavaScript" feature unless you have tested the payment on a real order. A delayed payment script can leave the button dead.

4. Make recalculations quick

• Simplify shipping zones and rules where you can.
• Check how long the update_order_review request takes, and compare it with and without each shipping, tax and discount plugin.
• Ask the plugin's developer whether it calls an outside service on each recalculation, and whether it caches the answer.

5. Keep the page quiet

Use a simple template for the checkout. No slider, no promotional banner, no related products. A smaller page loads sooner and keeps attention on the form.

6. Do not speculate on it

If you use speculation rules, exclude the cart, checkout and account pages. A page that is loaded before the visitor sees it can show stale basket data, and it can run payment scripts early.

How to test a checkout

An online tester starts with an empty cart, and WooCommerce redirects a visit to the checkout with an empty cart to the cart page. To test the real page, use Chrome's own Lighthouse panel:

1. Open a private window, so that extensions and old data do not affect the result.
2. Add a product to the cart and go to the checkout, in that window.
3. Open DevTools and go to the Lighthouse panel. Choose Navigation mode and the device you want to test.
4. Run it. Lighthouse reloads the page you are on.

Lighthouse 13.5 resets some stored data before a run: file systems, the shader cache, service workers and cache storage, as well as the browser's HTTP cache. According to its settings, cookies are not on that list, so the cart session survives. The Chrome documentation describes a Clear Storage checkbox for this reset and says to leave it on to audit a first-time visitor's experience. Check that the report shows the checkout form and not an empty-cart message.

Then test what a score cannot show:

• Change a country and a shipping method, and time the recalculation in the Network panel.
• Use a phone with a slower connection, and watch where it waits.
• Run a test purchase with a payment method in test mode, from the product page to the confirmation. Do this after every change.

Mistakes to avoid

• Caching the checkout. Never. It shows one customer another's data.
• Judging it from an empty-cart test. The result will not describe the page your customers use.
• Removing scripts without a test purchase. A fast checkout that cannot take payment is worse than a slow one.
• Removing fields that tax or shipping needs. The recalculation then fails or is wrong.
• Adding a plugin to fix speed on this page. Every plugin is more code in the request.

Check your own page

The free audit cannot reach a checkout with a cart, so run it on a product page for a baseline, then do the Lighthouse test above with an item in the cart. Open 3rd parties, Reduce unused JavaScript and Document request latency. If the server response is slow, work on hosting and caching. If the scripts are heavy, start with the payment and tracking tools. Then time the recalculation.

Sources

• WooCommerce source code: checkout.js (when and how the totals are recalculated), class-wc-checkout.php (the field and guest checkout filters and options), class-wc-cache-helper.php, class-wc-frontend-scripts.php and wc-template-functions.php (the redirect from an empty-cart checkout).
• Ecommerce chapter, Web Almanac 2025: payments as a dependency surface.
• Lighthouse in Chrome DevTools and the Lighthouse configuration source: the Clear Storage option and which storage types are reset.