To speed up WooCommerce checkout, first identify whether your store uses the newer Checkout Block or the Classic shortcode checkout. Then measure the checkout itself rather than guessing: test the initial page load, shipping and tax updates, and the final Place Order request separately. The biggest improvements usually come from reducing server response time, using compatible object caching and HPOS, removing unnecessary checkout scripts, and identifying slow payment, shipping, tax, or plugin requests.
Checkout is the one page on your store where speed is not a nice-to-have. A slow product page loses browsing time. A slow checkout loses a sale someone had already decided to make. This guide treats checkout as its own problem, separate from general store speed, because the fixes here are more specific and the mistake most guides make is giving you jQuery-era advice for a page that, on a lot of stores now, does not run jQuery at all.
Why checkout speed matters more than the rest of your store
Cart abandonment across ecommerce remains extremely high. Baymard Institute’s current benchmark puts the average documented cart abandonment rate at roughly 70%, and its research shows that checkout friction remains a major contributor. Among shoppers who abandon for reasons other than simply browsing, 17% cite a checkout that feels too long or complicated, while another 17% report abandoning because the website had errors or crashed.
Checkout performance matters because these shoppers are no longer casually browsing. They have already selected a product and entered the buying process. A slow page load, delayed shipping calculation, unresponsive payment option, or Place Order button that keeps spinning creates friction at the point closest to conversion.
That is also why checkout should be optimized separately from the rest of a WooCommerce store. Product and category pages can often benefit heavily from page caching, while checkout contains customer-specific cart, shipping, tax, session, and payment data that must remain dynamic.
Step 1: Find out which checkout you are actually running
This is the step almost every guide skips, and it decides which of the fixes below actually apply to you.
Since WooCommerce 8.3, released in November 2023, new stores default to the Checkout block, a React-based checkout that talks to WordPress through the WooCommerce Store API. Older stores, and some that have simply never been touched, still run the Classic checkout, built on the [woocommerce_checkout] shortcode and traditional PHP hooks.
Check which one you have: go to WooCommerce, then Settings, then Advanced, then Page Setup, and open your Checkout page in the editor. If you see the shortcode [woocommerce_checkout], you are on Classic. If you see a Checkout block in the block editor, you are on the newer system.
Why this matters immediately: the Block and Classic checkouts use different extension systems. The Checkout Block communicates through WooCommerce’s Store API, while the Classic checkout relies more heavily on traditional PHP hooks and AJAX requests.
An extension built only for the Classic checkout may not behave correctly after a store moves to the Checkout Block. Depending on the extension, a feature may disappear, display an incompatibility notice, produce an error, or cause part of the checkout experience to stop working.
If a checkout customization, payment option, fee, or field stopped working after switching checkout types, check the extension’s documentation for confirmed Checkout Block and Store API compatibility before assuming the problem is general WooCommerce performance.
Classic checkout still works and still receives security and bug fixes, but WooCommerce’s own documentation is clear that new feature development is focused on the block. Neither is wrong to run. What is wrong is applying advice written for one to a store running the other.
Step 2: Diagnose before changing anything
Test the real checkout experience with at least one product in the cart. Checkout performance is more than a single page-load score because WooCommerce continues making dynamic requests as the customer enters an address, selects shipping, chooses a payment method, and places the order.
Open the checkout in Chrome, then go to:
Chrome DevTools → Lighthouse
Run a mobile performance test to establish a page-load baseline.
Then open:
Chrome DevTools → Network
Use the Network tab while you change the shipping address, select a shipping method, choose a payment gateway, and place a test order. Look for requests that are unusually slow, return errors, or remain pending for several seconds.
PageSpeed Insights can still provide a useful public-page baseline, but it may not reproduce the same cart, session, and checkout state as a real shopper. For checkout-specific diagnosis, testing an actual cart session in your browser is more useful.
You can also use Query Monitor on a staging or controlled test environment to inspect slow database queries, PHP hooks, HTTP API calls, and scripts. Keep in mind that diagnostic plugins add their own overhead, so use them to identify bottlenecks rather than as your final performance benchmark.
Write down your baseline before making changes and test again after each fix.
Measure the Slow Part of Checkout, Not Just the Page Load
A checkout can load quickly and still feel slow when the customer changes an address or clicks Place Order. Measure these interactions separately.
For Classic Checkout, look in the Network tab for WooCommerce AJAX requests such as:
?wc-ajax=update_order_review
?wc-ajax=checkout
A slow update_order_review request often points toward shipping calculations, tax logic, checkout hooks, or server-side processing.
For the Checkout Block, look for WooCommerce Store API requests under paths such as:
/wp-json/wc/store/v1/cart
/wp-json/wc/store/v1/checkout
If one of these requests takes several seconds, inspect its Timing and Response information before optimizing unrelated images or frontend files.
This distinction helps you determine whether the problem is the initial page render, WooCommerce’s backend processing, or a third-party service involved during checkout.
The real bottlenecks, and the checkout-specific fix for each
Check Whether Cart Fragments Are Actually Loading
Older WooCommerce performance guides often recommend disabling cart fragments immediately, but modern WooCommerce versions no longer load the cart-fragments script universally in the same way they once did.
Before changing anything, open Chrome DevTools → Network and search for:
wc-cart-fragments
or
get_refreshed_fragments
If neither appears during checkout, cart fragments are not your bottleneck and there is nothing to optimize here.
If they are present because your theme, classic Mini-Cart widget, or another plugin depends on them, check whether that functionality is actually required on checkout. Only disable or conditionally unload the script after confirming that doing so does not break the site’s cart count or Mini-Cart behavior elsewhere.
Do not disable cart fragments site-wide simply because an older optimization guide recommends it.
Persistent Object Caching
WooCommerce checkout cannot normally rely on full-page caching, but persistent object caching can reduce repeated database work during dynamic requests.
Redis and Memcached are common options. If your hosting provider supports persistent object caching, ask whether Redis or Memcached is available and whether it is already enabled for WordPress.
Do not install a Redis cache plugin and assume that Redis is working. The server also needs a functioning Redis service for the plugin to connect to.
After enabling object caching, repeat the same checkout tests you recorded earlier. The improvement will vary depending on your database size, plugins, product types, and how much repeated data WooCommerce needs during each request.
Enable High-Performance Order Storage
High-Performance Order Storage, or HPOS, moves WooCommerce order data away from the general WordPress posts and postmeta tables into dedicated order tables designed for ecommerce queries.
WooCommerce has enabled HPOS by default for new installations since version 8.2. Existing stores can check it under:
WooCommerce → Settings → Advanced → Features
WooCommerce’s own performance testing during the HPOS rollout showed significant improvements to order creation and checkout performance, although the exact gain varies between stores.
Before enabling HPOS on an older store, create a backup and confirm that your active payment, subscription, reporting, fulfillment, and other order-related extensions are HPOS compatible. Test the change on staging first if the store has complex custom integrations.
Check Product Object Caching in WooCommerce 11.0
WooCommerce 11.0 introduced another performance feature worth testing: Product Object Caching.
For stores where it is available, check:
WooCommerce → Settings → Advanced → Features → Cache Product Objects
The feature reduces repeated work when WooCommerce loads the same product objects multiple times during a request. WooCommerce’s own benchmarks have shown checkout-processing improvements for some product types, particularly bundles and more complex product setups.
Performance gains vary significantly depending on the extensions and products used by the store, so enable the feature on staging first if you run custom product, subscription, bundle, or checkout integrations.
If you are running an older WooCommerce version, update on staging before treating newer performance features as missing optimization opportunities.
Check Whether WooCommerce Cleanup Jobs Are Running Correctly
Database bloat can slow a busy WooCommerce store, but modern WooCommerce already performs several cleanup tasks automatically. Expired transients and customer sessions should not simply grow forever on a healthy installation.
Instead of deleting old WooCommerce data blindly, first check whether scheduled cleanup tasks are running correctly.
Go to:
WooCommerce → Status → Scheduled Actions
Look for a large backlog of failed or past-due actions.
You can also go to:
WooCommerce → Status → Tools
WooCommerce provides tools for clearing customer sessions, cleaning expired transients, and performing other maintenance tasks.
If thousands of scheduled actions are failing or overdue, identify which plugin or process created them before deleting anything. A broken background task can continue recreating the same database load even after a manual cleanup.
Always back up the database before performing bulk cleanup on a production store.
Check for a Scheduled Actions Backlog
WooCommerce and many extensions use Action Scheduler for background jobs such as analytics, subscriptions, webhooks, email processing, imports, and other recurring tasks.
Go to:
WooCommerce → Status → Scheduled Actions
Filter for:
- Failed
- Pending
- Past-due actions
A small number of scheduled actions is normal. A large or constantly growing backlog can increase database and server load.
Look at the Hook and Group columns to identify which plugin is generating the actions. Fix the underlying extension, cron, or server problem rather than simply deleting all scheduled tasks.
Do not bulk-delete unfamiliar actions on a live store. Payment, subscription, inventory, and fulfillment extensions may rely on them.
Too many scripts loading specifically on checkout
This is different from your general plugin count. A plugin can be lightweight everywhere else on your site and still load unnecessary CSS or JavaScript on checkout specifically, because that page has more moving parts (payment fields, shipping calculations, coupon logic) that plugins hook into. Use Query Monitor’s results from Step 2 to see what is actually loading there, and a tool like Perfmatters or Asset CleanUp to disable scripts on a per-page basis rather than site-wide.
Slow Payment, Shipping, and Tax Requests
Some checkout delays do not come from WordPress itself.
WooCommerce may need to communicate with a payment gateway, live shipping-rate service, tax provider, fraud-prevention system, address-validation service, CRM, inventory platform, or another external API during checkout.
If the page loads quickly but shipping updates or the Place Order action takes several seconds, open:
Chrome DevTools → Network
Perform the slow action again and look for requests that remain pending or take significantly longer than the others.
Also check:
WooCommerce → Status → Logs
If your payment, shipping, or tax extension supports logging, inspect entries created at the same time as the slow checkout request.
An external API timeout will not be fixed by compressing images or installing another caching plugin. You need to identify which integration is delaying the checkout response.
Hosting and server response time
If your server’s Time to First Byte is consistently high, no checkout-specific fix above will fully compensate, because checkout cannot be page-cached the way a static product page can and depends more heavily on raw server response for every request. If PageSpeed Insights flags a high server response time, that is a hosting problem rather than a checkout configuration problem, and it is worth fixing first since it sets the ceiling for everything else on this list.
Reduce Checkout Friction, Not Just Load Time
Reducing unnecessary checkout fields is primarily a conversion and usability improvement rather than a substitute for fixing slow server requests.
Baymard Institute’s current checkout research finds that the average checkout contains almost 15 form fields, while many checkout flows can be significantly shorter. Fewer unnecessary inputs are particularly valuable on mobile, where typing and correcting form data creates additional friction.
Before removing anything, consider what your payment gateway, shipping provider, tax configuration, fraud-prevention tools, and fulfillment process actually require.
Common fields worth reviewing include:
- Company name
- Address line 2
- Phone number
- Order notes
- Custom marketing or referral fields
For the WooCommerce Checkout Block, core fields such as Company, Phone, and Address Line 2 can be configured through the checkout editor. More complex field removal or customization should follow WooCommerce’s supported Checkout Block APIs.
Do not remove address or contact fields simply to make the form shorter if your payment gateway, taxes, shipping rules, or fraud checks depend on them.
The goal is not the fewest possible fields. It is the fewest fields required to complete the order accurately and safely.
Troubleshooting Block checkout specifically
If you are on Block checkout and something is not working rather than just being slow, the diagnostic path is different from a typical WordPress plugin conflict.
If the problem has moved beyond slow performance and checkout is failing completely, use our guide to fixing a WooCommerce checkout that is not working before continuing with performance optimization.
Disable other plugins one at a time and reload checkout after each, the same method used for diagnosing any plugin issue, but pay attention to whether the failure is a broken layout or something simply missing entirely, since Block checkout tends to fail silently rather than visibly. Switch temporarily to a default theme like Storefront to rule out a theme conflict.
And if a specific customization worked before but stopped after your store moved to Block checkout, check whether that plugin has documented Store API support before assuming it is broken; many older checkout plugins were built for the shortcode only and were never updated for the block system at all.
What not to do
Do not stack multiple caching plugins. Checkout pages are dynamic and sensitive to caching mistakes specifically; an aggressively cached checkout can serve a shopper someone else’s cart or a stale total, which is a far worse outcome than a slow page.
Do not disable cart fragments site-wide without checking your theme first. Some themes depend on that same script to update the header cart icon everywhere, not just on checkout, and disabling it blindly breaks that display elsewhere.
Do not install a checkout field editor without confirming it supports your checkout type. A plugin built for the Classic shortcode era can silently fail to apply any changes on Block checkout, and you will not get an error telling you why.
Do not chase a perfect PageSpeed score on checkout at the expense of function. A fast checkout that reliably completes orders beats a marginally faster one that occasionally drops a field or a coupon code.
What Results Should You Realistically Expect?
There is no universal target improvement because WooCommerce checkout performance depends on hosting, traffic, order volume, product types, payment gateways, shipping calculations, extensions, and custom code.
Focus on improving the same measurements you recorded before optimization:
- Initial checkout page load
- Shipping and tax update response
- Payment-method loading
- Place Order response time
- Failed or unusually slow Network requests
- Slow database or external API calls
Hosting, HPOS, persistent object caching, and inefficient backend requests can produce large improvements on some stores. Script cleanup and frontend changes may produce smaller gains where the real bottleneck is server-side.
The goal is not a perfect performance score. The goal is a checkout that consistently loads, updates totals, accepts payment, and completes orders without noticeable delays.
Conclusion
Checkout speed is worth solving on its own terms rather than folding into general store optimization, because a slow checkout loses a customer who had already decided to buy. Start by confirming whether you run Block or Classic checkout, since the fix path and the troubleshooting method both depend on it, and Block checkout’s tendency to fail silently on unsupported extensions is a real, underexplained risk.
Diagnose the actual checkout page with PageSpeed Insights and Query Monitor before changing anything. Then work through the technical levers in order of impact: hosting and TTFB as the foundation, object caching and HPOS as the two biggest single changes, database cleanup and a per-page script audit next, and field reduction as a genuine performance lever rather than only a UX one.Treat abandonment statistics as the reason this work matters, not as a substitute for testing your own checkout page directly.
WooCommerce Checkout Still Slow?
If you’ve improved caching, HPOS, plugins, scripts, and server settings but checkout is still slow, the bottleneck may be deeper in your database, custom code, payment gateway, shipping calculations, or third-party integrations.
Survyc can diagnose the complete WooCommerce checkout path, identify what is delaying the customer experience, and recommend the safest fix without blindly disabling functionality your store depends on.
Contact: Speed Up My WooCommerce Checkout
Frequently Asked Questions
Why Is update_order_review Slow in WooCommerce?
On the Classic WooCommerce checkout, update_order_review recalculates checkout information such as totals, shipping methods, taxes, and other data affected by checkout hooks. If the request is slow, check Chrome DevTools → Network, WooCommerce logs, shipping and tax integrations, plugin hooks, and your server response time to identify what is delaying the request.
Why Is the WooCommerce Checkout Block Slow?
The Checkout Block relies heavily on the WooCommerce Store API. Slow Store API responses can come from server performance, database queries, checkout extensions, shipping or tax calculations, payment integrations, or other custom logic. Use Chrome DevTools → Network and inspect /wp-json/wc/store/v1/ requests to determine which interaction is slow before making optimization changes.
Why is my WooCommerce checkout page slow?
Usually a combination of missing object caching, High-Performance Order Storage not enabled, database bloat from old sessions and transients, and unnecessary scripts loading specifically on the checkout page. Server response time sets the ceiling for all of it. Diagnose with PageSpeed Insights on the checkout URL and Query Monitor before changing settings.
Should I use Block checkout or Classic checkout?
Block checkout, WooCommerce’s default since version 8.3, is generally faster and receives ongoing feature development. Classic checkout still works and gets security fixes, so an existing store running it smoothly does not need to switch urgently. The decision matters most for compatibility: confirm any checkout plugin supports whichever version you use.
Does enabling High-Performance Order Storage speed up Woocommerce checkout?
Yes, measurably on stores with real order volume. HPOS moves order data into dedicated database tables instead of sharing the general posts table with every blog post and page on the site, which speeds up the queries checkout depends on. Enable it under WooCommerce, Settings, Advanced, Features.
How many fields should a WooCommerce checkout have?
The average WooCommerce checkout carries close to fifteen fields; most stores can reduce that to seven or fewer without losing information they actually need. Company name, a second address line, an extra phone field and order notes are commonly safe to remove or make optional.
Why did my checkout plugin stop working after switching to Block checkout?
Block checkout uses the WooCommerce Store API rather than the PHP hooks Classic checkout relies on. A plugin built only for the shortcode-era checkout does not degrade or error when it hits Block checkout, it simply does not run. Check the plugin’s documentation for confirmed Store API support before troubleshooting further.
How do I test my WooCommerce checkout speed?
Run your actual checkout URL, not your homepage, through PageSpeed Insights on the mobile tab, and install the free Query Monitor plugin to see exactly which scripts and database queries load on that page. Test after each change individually so you know which fix actually moved the numbers.
