The last page is the slowest
Product pages load quickly. Then a customer adds something to the basket, goes to checkout, and waits. They enter a postcode and the order summary spins while shipping recalculates. They choose a payment method and wait again. Some press the button twice. Some give up and go back to the marketplace where they found you.
Checking the shop yourself on a quiet morning, it seems fine. Under real traffic, with customers in the checkout at the same time, it gets noticeably worse.
Why checkout is different
Most of a shop can be served from a cache: the same product page shown to everyone. Cart and checkout cannot, because they are personal to each customer. Every request goes to WordPress, runs every active plugin and queries the database. So problems that caching hides elsewhere appear in full at checkout.
| What slows checkout | Why |
|---|---|
| Shipping rates fetched live from couriers | Each postcode change waits on an external server |
| Many plugins hooking into cart updates | Every small change reruns all of them |
| Order data in the old posts tables | Large shops make order queries slower over time |
| Several payment and fraud scripts loading at once | The page waits on third-party servers |
| Cart fragments refreshing on every page | Uncached background requests add server load for everyone |
| Hosting sized for cached traffic | Too few PHP workers, so checkout requests queue |
The last row is common. A shop can look fine on hosting that serves cached pages well, then run out of capacity as soon as several people are checking out together.
What the slow checkout costs
Every abandoned checkout is someone who chose a product, had the intention to buy and was lost at the final step. It is also the most expensive traffic to lose, because you have usually paid in ads or effort to get them there. Double-clicked payment buttons create duplicate orders and refunds for your team to untangle. And support gets messages from customers unsure whether their order went through.
How we speed the checkout up
- Profile real cart and checkout requests on a staging copy with realistic data, recording time spent in each plugin, database query and external call.
- Remove or restrict plugins that run on checkout without needing to be there, such as marketing widgets, sliders and page builder assets.
- Speed up shipping: cache courier rates for the same basket and postcode, use table rates where live quotes add nothing, and set sensible timeouts so a slow courier cannot hold the page.
- Move orders to WooCommerce's High-Performance Order Storage if the shop still uses the older tables, after testing extensions for compatibility.
- Load payment scripts only on the checkout, keep to the payment options customers actually use, and make sure the pay button cannot submit twice.
- Tune the database, add object caching such as Redis, and size PHP workers and hosting for uncached checkout traffic.
- Load test the checkout with simulated customers, then measure again after changes go live.
We also look at the checkout form itself. Unnecessary fields, forced account creation and surprise costs at the last step lose buyers as surely as slowness.
What your customers notice
Postcode and payment changes update quickly. The checkout keeps responding when the shop is busy. Customers get a clear confirmation, duplicate orders stop, and your team has fewer anxious emails to answer. You also get a measured before and after, and a list of what changed, so the next plugin added to checkout is judged against it.
Is your checkout losing sales?
- The basket and checkout pages are noticeably slower than product pages
- Shipping totals spin when a postcode is entered
- Customers email to ask if their order went through
- Duplicate orders appear from double clicks
- The shop slows down during sales or busy periods
- The shop has a large order history and still uses the old order tables