Why the checkout is slow when the rest is fast
A store with a good page cache serves its product pages in a few hundred milliseconds. Then the customer reaches the checkout and waits three seconds. The checkout is personalised: it has this customer's cart, their address, their shipping options. No cache can serve it, so every request runs WooCommerce, the theme and every plugin from scratch, and every script the site loads gets a chance to slow the one page where slowness costs the most.
Here is where the time actually goes, and what to do about each part.
1. Server time: the uncached request
The checkout request runs the full stack. On a store with a heavy theme and thirty plugins, generating the page can take one to three seconds before a byte is sent.
Measure it. Time to first byte on the checkout URL, from a real browser, logged in as a customer with items in the cart.
Fix it. A persistent object cache (Redis or Memcached) is the single biggest server-side win for checkout, because it caches the hundreds of option and meta lookups WooCommerce makes per request. Then profile with Query Monitor: the plugins running expensive queries on every page load show up immediately. Common offenders are analytics plugins, related-products plugins and anything that scans the catalogue on init.
2. Cart fragments
WooCommerce's cart fragments script polls the server to keep the mini-cart count current. On many themes it fires on every page load, making an uncached AJAX request that runs the full stack again. On the checkout page it is pure overhead.
Fix it. Dequeue wc-cart-fragments everywhere except where the mini-cart actually needs it, or replace the polling with the Store API's cart endpoint, which is lighter and cacheable per session. Several performance plugins offer a toggle; doing it in code is a few lines:
add_action( 'wp_enqueue_scripts', function () {
if ( is_checkout() || is_cart() ) {
wp_dequeue_script( 'wc-cart-fragments' );
}
}, 20 );3. Scripts that have no business on the checkout
The checkout page typically loads everything the theme loads everywhere: sliders, animation libraries, the blog's syntax highlighter, three fonts, a chat widget, a session recorder, the tag manager with twenty tags. None of it helps the customer pay, and all of it competes with the payment form for the main thread.
Measure it. A performance trace on the checkout, on a throttled mobile profile, sorted by script execution time.
Fix it. Conditionally dequeue on is_checkout(). Defer the tag manager until after the payment form has rendered. Load the chat widget on click, not on load. Remove the session recorder from the checkout entirely; it is also a privacy problem there. The checkout should load WooCommerce's own scripts, the payment gateway's, and almost nothing else.
4. The payment gateway's own weight
Stripe, PayPal and their peers load their JavaScript SDKs on the checkout. Necessary, and heavy. Two things help: load only the gateways that are actually enabled, since some plugins load the SDK for disabled methods, and make sure the SDKs load after the checkout markup rather than blocking it.
5. Checkout block versus shortcode
The checkout block renders client-side from the Store API and, once loaded, updates shipping and totals without full page requests. The shortcode checkout re-posts the form for many changes. The block is generally faster to interact with once loaded and heavier to load initially. On a well-optimised site the block wins; on a heavy site it adds to the pile. Either way the fixes above apply; do them first, then evaluate the block on your store.
6. Shipping and tax calculations
Live-rate shipping plugins call a carrier API when the address changes. Tax plugins call a tax service. Each call is a second or two the customer waits. Cache rates per address for the session, or pre-fetch when the address is entered rather than at the moment of update.
7. Images and fonts on the checkout
The checkout usually needs no hero image and one font. Themes that load a full-width banner and three web fonts on every page are spending the customer's connection on decoration at the wrong moment.
Measuring the result
Before and after, on the same store, on a throttled mobile profile: time to first byte, time until the payment form is interactive, and field INP from real customers if you have monitoring. The aim is a checkout that is interactive in under two seconds on a mid-range phone. Most stores that arrive at three or four seconds get there with the object cache, the fragment removal and the script pruning alone.
Where this fits
Checkout speed is the highest-return performance work on a store, because every millisecond is on the path to a payment. It is a standard part of WooCommerce performance work, and the profiling step is what turns "the checkout is slow" into a list of five specific things with a fixed price.