Most slow WooCommerce stores are not slow because of WooCommerce itself. They are slow because every visitor triggers a full PHP render, product images are far larger than they are displayed, and the theme loads scripts on pages that never use them. The good news: those are fixable without touching the checkout flow.
Start by measuring the right thing
Google’s Core Web Vitals give you a sensible target. A page is considered to have a good experience when Largest Contentful Paint (LCP) happens within 2.5 seconds, Interaction to Next Paint (INP) is 200 milliseconds or less, and Cumulative Layout Shift (CLS) is 0.1 or less — measured at the 75th percentile of real page loads, separately for mobile and desktop (web.dev).
Lab tools such as Lighthouse are useful for spotting problems on a single page, but they run one simulated visit. Field data from real visitors is what actually reflects your customers. Use the lab to debug and the field data to decide whether the fix worked.
Cache pages, but never the personal ones
Full-page caching is the biggest single improvement for a catalogue page: the server sends stored HTML instead of rebuilding it. The catch is that some WooCommerce pages are unique to each shopper. WooCommerce’s own documentation lists what to exclude from page caching (WooCommerce developer docs):
- The Cart, Checkout and My Account pages.
- Requests carrying the cookies
woocommerce_cart_hash,woocommerce_items_in_cart,wp_woocommerce_session_,woocommerce_recently_viewedandstore_notice[notice id].
After setting exclusions, test like a customer: add a product to the cart in a private window, reload the shop page, and confirm the mini-cart count is correct. Then log in and check that account pages show your own orders — not a cached copy of someone else’s view.
Fix image weight before anything else
Product photography is usually the heaviest part of a store. Three habits make a large difference:
- Upload sensibly sized originals. A 6000-pixel camera export is rarely needed for a product shown at 800 pixels.
- Let WordPress serve responsive sizes. WordPress generates intermediate sizes and outputs
srcset, so the browser can choose a smaller file on a phone — as long as your theme uses the standard image functions. - Use modern formats where your server supports them. WebP is widely supported and usually much smaller than JPEG at similar quality.
Do not lazy-load the main product or hero image. Since WordPress 6.3, core automatically adds fetchpriority="high" to the image it judges most likely to be the LCP element and avoids lazy-loading it (Make WordPress Core). Custom templates that hard-code loading="lazy" on the first image undo that work.
Load scripts only where they are used
Sliders, popups, form plugins and chat widgets often enqueue their assets on every URL. Audit a product page in your browser’s network panel and ask of each script: is it used on this page? Many plugins provide a setting or filter to load assets conditionally. The aim is not zero JavaScript; it is no JavaScript that does nothing.
Be careful with “optimisation” switches
Minifying and combining files can help, but aggressive options such as delaying all JavaScript are a common cause of broken add-to-cart buttons, payment fields that never appear and variation selectors that stop updating prices. Turn options on one at a time and run a full test order — including a payment-gateway test mode — after each change.
Keep the database and server healthy
- Run a currently supported PHP version — check php.net’s supported versions page before you plan an upgrade.
- Use High-Performance Order Storage where your extensions support it. It has been enabled by default for new stores since WooCommerce 8.2 and stores orders in dedicated tables rather than the posts table (WooCommerce docs).
- Watch scheduled actions under Tools → Scheduled Actions; thousands of failed or pending actions are a sign something needs attention.
A simple order of work
If you only have an afternoon: set up page caching with the correct exclusions, resize and convert your largest images, remove one or two unnecessary global scripts, then measure again. If you would like help, our website development and server management services cover exactly this kind of work.

