A slow checkout is rarely a slow page. It is a page that does a full server round-trip every time the customer touches a field. Country, postcode, shipping method, payment method — each change sends a request back to WordPress, which recalculates shipping and tax and rebuilds the order summary. The customer watches a spinner sit on top of the total they are trying to agree to.
Which is why optimising checkout for load time misses it entirely. By the time the customer is filling the form, loading is over. What they feel from that point on is interaction latency, and there is a Core Web Vital for exactly that. Below: what fires on each change, why the metric is INP rather than LCP, how the classic checkout and the Checkout block differ, and the order to fix things in.
Every field change is a round-trip to the server
You can watch this yourself in about thirty seconds. Put a product in the cart, open your checkout, open the browser’s network tab, and change the country. A request goes out and the totals grey over until it comes back. On a classic checkout that request is ?wc-ajax=update_order_review, described in WooCommerce’s own code reference as “AJAX update order review on checkout” (verified August 2026). Change the postcode: another one. Pick a different shipping method: another one. Switch from card to bank transfer: another one.
Each of those is not a small API call. It is WordPress booting, plugins loading, shipping zones being matched, tax rules being applied and the order review being rendered again — the full uncached request described in why a WooCommerce store is slow, only now it happens four or five times while one person fills in one form, and they are waiting for each one.
That reframes the whole problem. The question is not “how fast is my checkout page”. It is two questions:
- How many recalculations does a normal fill-in trigger?
- How expensive is each one?
Multiply them and you have the number the customer actually experiences. Halving either one halves the waiting. Most stores can do something about both, and most people optimise neither because both are invisible to a load-time score.
The worst version of the expensive-round-trip problem is live carrier rates. A shipping method that queries a carrier for a real quote puts a third-party HTTP request inside your recalculation. Your checkout is then exactly as fast as someone else’s API, on their bad days too.
On checkout the metric is INP, not LCP
Largest Contentful Paint asks when the main content appeared. On checkout, nobody cares: the customer arrived deliberately and is already looking at the form. Interaction to Next Paint asks how long the page takes to respond after they do something, which is the entire checkout experience.
INP is measured from real interactions — clicks, taps and key presses — across the whole visit, and it is the successor to First Input Delay, which only ever looked at the first one. Google’s thresholds are 200 milliseconds or less for good, above 500 milliseconds for poor, reported at the 75th percentile of page views (web.dev, verified August 2026). It also splits an interaction into three phases, and the split is useful here because a WooCommerce checkout can be slow in any of them for completely different reasons.
| Phase of the interaction | What it is | What makes it long on a WooCommerce checkout | What actually helps |
|---|---|---|---|
| Input delay | The wait before your code even starts running | The main thread is busy with analytics, chat widgets, A/B testing scripts and payment SDKs | Remove the third-party scripts that have no business on checkout; defer what is left |
| Processing | Your event handlers doing the work | The recalculation round-trip: shipping zones, tax, order review re-rendered on the server | Fewer recalculations, cheaper ones — and cached shipping rates instead of live lookups |
| Presentation delay | Getting the updated frame onto the screen | Rebuilding a heavy order-summary block, layout work, oversized product thumbnails in the review | A lighter order summary; update the part that changed, not the whole panel |
This is also where a familiar disappointment comes from: the store with a near-perfect Lighthouse score whose customers still complain that checkout drags. The lab test loads a page in a simulated browser and leaves. It never puts anything in a cart, never types an address, never changes a shipping method — so it never touches the part that is slow. The score was accurate and irrelevant at the same time.
Classic checkout and the Checkout block are not the same problem
Before changing anything, find out which checkout you have, because the advice diverges. WooCommerce made the Cart, Checkout and Order Confirmation blocks the default for new installations in version 8.3, released in November 2023, and left existing stores on what they already had (WooCommerce Developer Blog, verified August 2026). So a store built in 2021 and updated ever since is almost certainly still running the classic shortcode, and its owner has probably never been told there is a choice.
| Classic shortcode checkout | Checkout block | |
|---|---|---|
| How a field change is handled | Server rebuilds the order review and sends back HTML | Browser asks the Store API for data and re-renders in place |
| What the request costs | A full WordPress render on every change | A data response; the rendering happens client-side |
| Typical failure mode | Spinner over the totals after every input | A heavy JavaScript bundle, and extensions that force extra recalculations |
| Extension compatibility | Everything works; the ecosystem was built for it | Needs extensions that support the block — older ones may not |
| Who has it | Stores that existed before the switch, and anyone who kept the shortcode | The default for installations from WooCommerce 8.3 (November 2023) onward |
| Worth moving to? | — | Often yes, but only after checking every payment and shipping extension you rely on |
Moving to the block is a real improvement for a lot of stores and a genuine risk for some. The gateway and shipping extensions are the deciding factor, not the performance argument. Test it on a copy, run a real order through every payment method you accept, and only then decide.
What to do, in order
One change at a time, timing the same round-trip after each. If you change five things at once you will know the checkout improved and nothing about why.
- Count the round-trips. Fill in your own checkout with the network tab open, as a customer in your most common country. Write down how many recalculation requests it takes and how long each one lasts. That pair of numbers is your baseline.
- Strip the third-party scripts from checkout. Heatmaps, chat widgets, ad pixels, testing tools. They contribute nothing to a customer who has already decided to buy, and they compete for the main thread exactly when responsiveness matters most.
- Deal with live shipping rates. Cache them if the extension supports it, restrict them to the zones that genuinely need them, and set a sane fallback for when the carrier does not answer.
- Find the extension that recalculates too eagerly. Deactivate checkout-adjacent plugins one at a time on a staging copy and repeat the count. Fee calculators, currency switchers, points and rewards, custom field plugins — one of them is usually responsible for most of the cost.
- Lighten the order summary. Full-size product thumbnails and a summary panel rebuilt from scratch on every change both land squarely in presentation delay.
- Make the uncached request itself cheaper. Object caching, a clean options table, a database that is not carrying five years of expired transients. Every recalculation pays this cost, so every improvement here is multiplied by the number of round-trips.
- Then consider the Checkout block — with the extension check above done first.
When it is not worth it
Do not trade a working checkout for a faster one. This is the one page on the store where a bad change costs money immediately rather than gradually. Removing live rates from a store whose customers need accurate shipping costs, or switching to the block with a gateway that only half supports it, will lose you more orders than a two-second recalculation ever did. Speed on checkout is worth having right up to the point where it starts competing with certainty, and then it stops being worth having.
And if your checkout is abandoned rather than slow, this is the wrong fix. Forced account creation, shipping costs that appear at the last step, three payment methods nobody in your country uses — those lose orders at a scale that milliseconds do not reach. Time the round-trips first. If they come back fast and people still leave, the problem is the form, not the server, and no amount of optimisation will find it.
Where it does pay: a store with steady orders and a checkout that visibly stalls after every field, or one carrying a long tail of plugins nobody has audited. That is what our WooCommerce speed optimisation covers, checkout included, and it starts by counting round-trips rather than running a score. If the store is also moving host, do the move first — the reasoning is in migrating a store without losing orders.
Frequently asked questions
Why is my checkout slow even though the page itself loads quickly?
Because the slow part happens after the page has loaded. On a classic WooCommerce checkout, changing the country, the postcode, the shipping method or the payment method sends a request back to the server, which recalculates shipping and taxes and re-renders the order summary. The customer sees a spinner over the totals every time. A load-time score never captures any of that, because a load-time test never fills in a form.
Is the Checkout block faster than the classic shortcode checkout?
Usually, for a different reason than people expect. The block talks to the Store API and re-renders the summary in the browser, so a field change updates part of the interface instead of rebuilding the whole order review on the server. It is not automatic: an extension that hooks into every recalculation can make the block just as slow. The block has been the default for new installations since WooCommerce 8.3, in November 2023; stores that existed before that kept the shortcode unless someone switched them over.
Should I delete checkout fields to make it faster?
Remove the fields you do not use, because a shorter form converts better. Do not remove them expecting a speed gain: the cost is not the number of inputs on the page, it is how many of them trigger a recalculation. Cutting a phone number field changes nothing. Cutting a plugin that recalculates totals when that field changes is what you were actually after.
Do live carrier shipping rates slow down checkout?
They can, more than anything else on the page. A live-rate shipping method makes an HTTP request to the carrier while the customer waits, inside the same round-trip that recalculates the order. If the carrier is slow that day, your checkout is slow that day, and nothing on your server will fix it. Cache the rates where the extension allows it, and keep flat or table rates as the fallback when the lookup times out.
Will a one-page or multi-step checkout plugin make it faster?
It changes the layout, not the arithmetic. Most of these plugins add their own JavaScript on top of the existing checkout and often add more recalculations, not fewer. They can be worth having for conversion reasons. Buying one to fix a slow checkout usually means installing more code on the page you were trying to lighten.
How do I measure checkout speed properly?
Not with a load-time score. Open your own checkout with a product in the cart, open the browser network tab, and change the country. Time the request that fires, and count how many of them a full fill-in produces. Then look at INP in field data — it is measured from real interactions, with 200 milliseconds or less counted as good and anything above 500 milliseconds poor (web.dev, verified August 2026).
Sources (verified August 2026): WooCommerce code reference — WC_AJAX; WooCommerce Developer Blog — WooCommerce 8.3.0 released; WooCommerce — Store API; web.dev — Interaction to Next Paint.