WooCommerce Speed Optimisation

WooCommerce speed optimisation is different from speeding up an ordinary WordPress site, because a shop has pages that cannot be cached. Product and category pages can be served from cache like any other page. The cart, checkout and account pages are personal to each shopper, so every request runs PHP and hits the database. Those pages — the ones closest to the sale — are where slow plugins, weak hosting and heavy scripts hurt most.

This guide covers how to find where a WooCommerce store is actually slow, and the fixes for each type of page.

Why are WooCommerce stores slower than brochure sites?

On a brochure site, page caching hides most server inefficiency. On a shop, it only hides some of it. Whatever happens on the uncached pages happens for every shopper at the moment they are trying to pay.

Find the bottleneck first

Do not start by installing an optimisation plugin. Start by measuring each page type separately.

1. Check field data in Search Console. The Core Web Vitals report groups similar URLs, so product pages, category pages and checkout will usually show up as separate groups. That tells you which part of the store real shoppers find slow.
2. Measure server response on uncached pages. Add something to the basket, then time the cart and checkout loads. If the first byte takes well over a second, the problem is server-side. How to reduce server response time covers how to break that down.
3. Profile with Query Monitor on staging. It shows which queries and which plugins take the time on each page.
4. List the scripts loading on checkout. Open the browser's developer tools on the checkout page and see what is loading — chat widgets, review widgets, tracking pixels and sliders do not belong there.

Fixes for product and category pages

These pages can be cached, so the work is mostly front-end.

Images

Product photography is usually the heaviest thing on a shop. Upload images at a sensible size, let WordPress generate responsive sizes, serve modern formats such as WebP or AVIF, and do not lazy-load the main product image — it is usually the Largest Contentful Paint element. How images affect website speed and SEO covers the details.

Variable products

WooCommerce loads variation data for a variable product directly into the page when there are 30 or fewer variations, and switches to loading it on demand above that threshold. Products with hundreds of variations can make product pages heavy and slow to respond to selections. The threshold is adjustable, but very large variation sets are often better restructured — separate products, or fewer attribute combinations.

Galleries, sliders and widgets

Zoom libraries, sliders, swatches and review carousels each bring their own JavaScript. Keep the ones that help shoppers decide and remove the rest. Every script on a product page competes with the shopper's taps, which is what Interaction to Next Paint measures.

Make sure the cache is actually hit

Marketing links add tracking parameters, and some caches treat each unique URL as a new page. Confirm that your cache ignores common tracking parameters, or every visitor from an email or ad triggers a full page build.

Fixes for cart, checkout and account pages

These pages cannot hide behind a cache, so the server has to be fast.

Object caching

An object cache such as Redis keeps repeated database query results in memory. On a shop it makes a noticeable difference to uncached pages and to the admin area. It needs host support, which is a good reason to choose hosting built for WooCommerce.

High-Performance Order Storage

WooCommerce originally stored orders in the general WordPress posts tables. High-Performance Order Storage (HPOS) moves them into dedicated tables designed for orders. It has been the default for new stores since WooCommerce 8.2, according to WooCommerce's HPOS documentation, but existing stores are not migrated automatically. If your store predates it, check WooCommerce settings under Advanced, then Features. Confirm your extensions are compatible, switch on compatibility mode, test on staging, then enable it.

Cart fragments

Older WooCommerce setups loaded a "cart fragments" script on every page to keep the mini-cart count up to date, making an extra uncached request on each page view. Since WooCommerce 7.8, that script is only loaded where the mini-cart widget is displayed, per WooCommerce's developer guidance. Some themes and plugins still enqueue it everywhere, so check whether it loads on pages that do not need it.

Payment and checkout plugins

Payment gateways need their scripts on checkout, and nowhere else. Check that gateway, upsell and checkout-field plugins are not loading assets across the whole site. Fewer checkout plugins also mean fewer things that can break after an update.

Third-party scripts on checkout

Analytics and conversion tracking belong on the order confirmation page. Live chat, social widgets, heatmaps and review popups rarely belong on checkout at all. Each one adds download and execution time at the most sensitive moment in the visit.

Fixes for search and filtering

Default WordPress search is not built for product catalogues, and filter plugins can generate heavy queries for every combination of attributes. On larger stores:

• use a search solution designed for products, ideally with its own index
• limit filter combinations to the attributes shoppers actually use
• stop search engines crawling endless filter combinations, which wastes server time as well as crawl budget

Background tasks and database housekeeping

WooCommerce schedules background jobs through Action Scheduler. Failed or completed actions can pile up into very large tables if nothing cleans them up, along with expired sessions and transients. Check the scheduled actions list under WooCommerce, then Status, and investigate any plugin creating thousands of pending or failed jobs.

Hosting for a shop

A WooCommerce store needs more from hosting than a brochure site: enough PHP workers to handle simultaneous uncached requests, object caching, a current PHP version, and server-level caching that understands which WooCommerce pages must never be cached. Cheap shared hosting is often the bottleneck once a store has real traffic. Choosing web hosting for a UK small business covers what to ask.

The admin area counts too

Shop owners and staff spend hours a day in the WooCommerce admin: processing orders, editing products, checking stock. A slow admin is not a Core Web Vitals problem, but it is a real cost in staff time and frustration. The usual causes are the same as on checkout — no object cache, orders still in the old storage tables, plugins adding dashboard widgets and admin notices that run their own queries, and order list screens filtered by meta data. HPOS and object caching tend to help the admin as much as the shop front.

What not to do

Some popular speed advice backfires on a shop:

• Caching cart, checkout or account pages. Shoppers see each other's baskets, or checkout fails. Exclusions must be explicit, and most WooCommerce-aware caches set them for you — check that yours does.
• Deferring or delaying every script. Aggressive "delay all JavaScript" settings can break add-to-basket buttons, variation selectors and payment fields. Exclude WooCommerce and gateway scripts, then test.
• Combining and minifying everything blindly. On modern hosting with HTTP/2 or HTTP/3, bundling every file into one rarely helps and can break things that depend on load order.
• Removing WooCommerce scripts sitewide with a snippet from a forum. Some are needed in places you would not expect, such as a mini-cart in the header.
• Installing three optimisation plugins. They overlap, conflict, and make it impossible to tell which setting caused a problem.

Quick checks you can do today

1. Search Console, Core Web Vitals report: which page groups fail on mobile?
2. Add a product to the basket and time how long the cart page takes to start loading.
3. View the checkout page's scripts in developer tools and list anything that is not payment or essential tracking.
4. WooCommerce, Status: check the PHP version, the scheduled actions list and whether HPOS is enabled.
5. Open your largest product image and check its file size.

The order I work through

1. Field data and page-type split — find which pages are slow for real shoppers
2. Uncached server response on cart and checkout
3. Plugin and query profiling on staging
4. Object caching and HPOS
5. Checkout script clean-up
6. Product images and product page scripts
7. Search, filtering and background jobs
8. Hosting, if the server is still the limit

The WooCommerce performance optimisation showcase walks through this order in more detail, and WordPress caching explained covers why caching alone only solves part of the problem.

Test every change like it could break checkout

Because it can. Every performance change on a shop — a caching rule, a deferred script, a plugin removal — should be tested on staging with a real end-to-end order: add to basket, apply a coupon, pay with a test card, receive the emails. A faster checkout that silently fails is the most expensive optimisation there is.

WooCommerce speed in context

A fast store is easier to rank and easier to buy from, but speed is one input among several. Core Web Vitals explained covers how the metrics are judged, and if you are still deciding on a platform, the WooCommerce store development guide covers how to build a shop that does not need rescuing later.

For an existing store, the diagnosis and fixes are part of the WordPress development service; for keeping a fast store fast as plugins and products change, monthly speed checks are part of the website maintenance service.