Author: [TO BE CONFIRMED] · Published: October 25, 2026
Checkout is the one page in a store that cannot be cached. It is generated live, per shopper, on every visit — and it is the page where slowness costs money directly. A shopper who waits for a checkout to load, or watches it spin after clicking “Place order”, does not always wait. They leave, and the order is gone.
This guide works through the bottlenecks that actually slow a WooCommerce checkout, in the order that matters most, with fixes you can apply and measure.
First, measure the right thing
Do not start by installing optimisation plugins. Start by measuring checkout specifically:
Time to first byte (TTFB) on the checkout page, from a location near your customers. Slow TTFB points at the server — PHP, database, or workers.
Full checkout flow time: from “Place order” to the confirmation page. That includes the payment gateway round trip, which your server does not control but your choice of gateway does affect.
Core Web Vitals for the store overall: LCP (largest contentful paint) should be 2.5 seconds or less, INP (interaction to next paint) 200 ms or less, and CLS (cumulative layout shift) 0.1 or less, each at the 75th percentile of real users. A page passes only when all three are good — a fast LCP does not rescue a poor INP, and INP is the metric that most often catches stores out, because heavy JavaScript makes every tap wait its turn.
Measure on real devices and real connections, not just on your office Wi-Fi. Use PageSpeed Insights for field data and a staging copy for before-and-after comparisons. Record the numbers before you change anything, so you can tell whether a change helped.
1. Fix the server side first
Checkout slowness is usually a server problem before it is a front-end problem.
PHP workers. Each simultaneous checkout needs a PHP worker. If your plan has too few, checkouts queue during a sale and time out. Ask your host how many workers your plan includes and raise the number — or the plan — before a campaign, not during it.
PHP version. Run PHP 8.3 or 8.4, as set out in WooCommerce Hosting Requirements for a Growing Store. Older PHP is slower as well as less secure. Test the upgrade on staging with a full checkout before going live.
Database. Checkout reads and writes orders, stock, customer and session data. A slow database makes checkout slow. Keep MySQL 8.0+ or MariaDB 10.6+ current, enable object caching (Redis or Memcached), and look at the slow query log for the queries that run on checkout. A missing index on a large orders table can add seconds.
Cron. WooCommerce relies on WP-Cron for scheduled tasks such as order emails and stock updates. On a busy store, WP-Cron firing on page loads adds delay to real visits. Replace it with a real server cron job that runs every few minutes, and disable WP-Cron in wp-config.php — after testing on staging.
2. Keep the checkout page itself light
The checkout page should be the lightest page in your store, not the heaviest.
Audit the scripts that load on checkout. Open the checkout in your browser’s developer tools, filter the Network tab by JavaScript, and list every script. Anything you cannot identify gets investigated and, if it is not needed at checkout, removed or prevented from loading there. Chat widgets, tracking pixels, live-chat tools and marketing scripts all add delay and compete for the main thread.
Minimise checkout fields. Every field is friction and every plugin that adds a field adds code. Ask for only what the order and the payment actually need.
Use a single-page checkout if your theme supports it well, and test it thoroughly — a shorter flow helps only if it is also fast and reliable.
Avoid heavy page builders on checkout. A checkout built with a general-purpose builder carries code the checkout does not need. Use the standard WooCommerce checkout template, customised lightly, rather than rebuilding it in a builder.
Set image sizes correctly and do not load large product images or banners on the checkout page itself.
3. Fix the payment flow
The payment step is often the slowest part of checkout, and it is partly outside your control — but your choices shape it.
Use a reputable, tokenised gateway (such as Stripe, PayPal, or Square) so card data is handled by the gateway and your store never touches raw card numbers. This is also the foundation of PCI DSS compliance: WooCommerce itself is not a payment processor and does not make a store compliant by itself — compliance remains the store owner’s responsibility, and the correct Self-Assessment Questionnaire depends on how checkout handles card data.
Prefer hosted or embedded gateway fields over a custom card form. A custom form that collects card data on your own domain can move you into a stricter PCI DSS category (SAQ A-EP or SAQ D) and adds a quarterly vulnerability-scan obligation. A redirect or hosted-field flow usually keeps the burden lighter. Confirm the category with your payment provider or acquirer, not by guessing from another store’s setup.
Watch PCI DSS 4.0’s checkout script rules. Requirements 6.4.3 and 11.6.1, which became mandatory on 31 March 2025, require payment-page scripts to be inventoried, authorised and monitored for unauthorised change. That is another reason to keep the script list on checkout short and known: every script counts, including tracking pixels and chat widgets. Audit the list each time you add a plugin that loads on checkout.
Test the gateway in its live mode, on staging, before a sale. Sandbox and live can behave differently, particularly around 3-D Secure, redirects, and webhook callbacks. A payment that succeeds in testing but fails live is a lost order and a support ticket.
Make failures recoverable. If a payment fails, the shopper should land back on checkout with their cart intact and a clear message — not on an error page with an empty cart.
4. Cache correctly — and know what cannot be cached
Cart, checkout and account pages must never be cached for one shopper and served to another. Configure your cache and CDN to exclude them explicitly, and test with two different browsers logged in as two different users: add different items to each cart and confirm neither sees the other’s cart.
What can be cached aggressively: product images, CSS, JavaScript and fonts, served through a CDN with sensible cache headers. Returning visitors should reuse those files instead of downloading them again. That reduces both load time and transfer — see Bandwidth Transfer Limits and Port Speed Explained.
5. Test under load before a sale
A checkout that is fast for one shopper can collapse for fifty at once. Before a campaign:
Rehearse the full flow on staging: browse, add to cart, check out, pay (in the gateway’s test mode), receive the confirmation email, and process a refund.
If you can, run a modest load test on staging with concurrent checkouts and watch PHP workers, CPU, database and response times.
Check that order emails send promptly — a slow mail queue makes customers think the order failed, and they order twice.
PHP 8.3 or 8.4, enough workers for peak concurrency, and a real cron job instead of WP-Cron.
MySQL 8.0+/MariaDB 10.6+, object caching enabled, slow queries reviewed.
NVMe storage for the database.
Checkout scripts audited; no unidentified JavaScript on the payment page.
Tokenised gateway, correct PCI DSS category confirmed with the provider, hosted or embedded card fields.
Cart, checkout and account pages excluded from all caching.
Full checkout tested on staging, including payment, emails and refunds, before every campaign.
The bottom line
A fast checkout is not one optimisation; it is the absence of bottlenecks at every step — server, database, scripts, payment flow and caching. Fix the server side first, keep the checkout page light and its script list known, choose a payment flow that keeps PCI DSS scope small, and test the whole journey under load before it matters. The shoppers who complete checkout will never tell you it was fast. The ones who leave because it was slow will not tell you either.
For hosting that keeps checkout fast at peak, see our WooCommerce hosting plans. [TO BE CONFIRMED: Offshore Hosting WooCommerce PHP worker counts and object-caching availability.]
Sources
CodeItBro — Optimizing Core Web Vitals in SSR React Apps (thresholds): https://www.codeitbro.com/blog/optimizing-core-web-vitals-in-react-apps
POLPROG — Core Web Vitals 2026: LCP, INP and CLS in practice: https://polprog.pl/en/learning/core-web-vitals-2026-lcp-inp-cls-in-practice
DevDiggers — Is WooCommerce PCI Compliant? What You Must Do in 2026: https://devdiggers.com/is-woocommerce-pci-compliant/
WebHelpAgency — WooCommerce Security: Protecting Your Store and Customer Data: https://webhelpagency.com/blog/woocommerce-security/
Email on your own domain looks professional and stays yours when you change providers. This guide explains what business email hosting involves, how it differs from free webmail, and the DNS and deliverability pieces that make it work.
Latency figures are widely quoted and widely misunderstood. This guide explains what ping measures, which hop actually matters, and the limits of what a VPS can do.
Webhooks, queue mode, and execution retention decide whether n8n stays fast or slowly fills its database. This guide explains each one and the settings that matter.