WooCommerce Speed Optimization: How WooCommerce Experts Make a Store Faster

A slow WooCommerce store is expensive in a way a slow blog is not: every extra second on a product or checkout page is measured in abandoned carts. Yet the most common "fix" — installing a caching plugin — barely touches the pages that matter, because cart, checkout and logged-in account pages cannot be cached. Making those fast is engineering work, and it is what WooCommerce experts spend a large part of their time on.

This is the sequence we follow on a store performance engagement, with the targets we aim for and the reasons each step matters.

Full-page caching makes the pages that were already fast faster. The pages that make money — cart, checkout, my-account, logged-in browsing — need cart-fragment control, a lighter checkout, an object cache, indexed queries and right-sized assets. Measure first, fix the biggest thing, measure again.

Step 0: measure, do not guess

Before touching anything we collect three things:

• Field data: real-user Core Web Vitals from the Chrome UX Report or Search Console. Google's thresholds are the targets — LCP under 2.5 s, INP under 200 ms, CLS under 0.1 — measured at the 75th percentile on mobile.
• A server-side profile: time to first byte, number of database queries and the slowest ones, per page type (home, category, product, cart, checkout, account). Query Monitor and a New Relic-style APM are the tools.
• A request waterfall: every script, style, font and image the page loads, with its size and whether it blocks rendering.

The profile usually points at two or three causes that explain most of the slowness. Fixing those first is what makes the rest worthwhile.

Step 1: tame cart fragments

WooCommerce refreshes the mini-cart with an AJAX call (wc-ajax=get_refreshed_fragments) on every page load, including pages with no cart on them. On an uncached store that call is a full WordPress bootstrap — commonly 0.5–2 seconds of server time per visitor per page — and it delays interactivity because the script runs early.

What experts do: dequeue wc-cart-fragments on pages that do not need it, or replace it with a lightweight cart counter that updates only when something is actually added to the cart. On many stores this alone moves the PageSpeed score by 15–25 points.

Step 2: make the checkout page light

Checkout is where the money is and where the most third-party JavaScript accumulates: every payment gateway's SDK, marketing pixels, live chat, address autocomplete, review widgets, the theme's slider library. We audit the checkout waterfall and:

• load each gateway's script only when that gateway is selected;
• defer pixels and chat until the page is idle;
• dequeue theme and plugin assets that have no business on checkout (sliders, galleries, contact-form scripts);
• reserve space for payment iframes so they do not shift the layout (CLS);
• test the result on a mid-range Android phone over 4G, because that is where customers are.

A checkout that renders in under 1.5 seconds and responds to taps instantly is achievable on almost any store.

Step 3: add an object cache (Redis)

WooCommerce runs dozens of database queries per page to load options, product meta, terms and sessions. A persistent object cache (Redis or Memcached) keeps the results in memory between requests. Properly configured it typically cuts database queries by 60–80% and brings time to first byte for uncached, logged-in pages from around 800 ms to under 200 ms. Sessions can also live in Redis, which removes database locking when many customers are checking out at once.

Full-page caching sits on top of this, with /cart/, /checkout/, /my-account/ and anyone holding a cart cookie excluded — the standard setup with WP Rocket, LiteSpeed or a hosting-level cache.

Step 4: fix the database

Stores accumulate weight: expired transients, autoloaded options that grow to several megabytes, post revisions, action-scheduler logs, orphaned meta. And WooCommerce's product listings depend on tables that need the right indexes.

Typical fixes: purge expired transients, set large rarely-used options to autoload = no (keep autoloaded data under about 1 MB), prune Action Scheduler history, add indexes to the meta and product lookup tables where the profile shows slow queries, and migrate to high-performance order storage (HPOS) so orders live in purpose-built tables instead of the posts table. On stores with tens of thousands of orders, HPOS alone changes the admin from painful to instant.

Step 5: rewrite the queries plugins left behind

The slowest thing on many stores is a plugin doing something on every request that should happen once: recalculating role-based prices for the whole catalogue, running a meta_query across every product to build a filter, loading every variation to display a price range. These do not show up in a caching plugin's report; they show up in the query profile.

The fix is code: cache the calculation per request, move it to the product lookup table, or replace the plugin with a purpose-built one that does the job efficiently. This is where WooCommerce experts earn their keep — and why wholesale stores with complex pricing in particular need one coherent B2B layer rather than a stack of pricing plugins.

Step 6: images and fonts

Product images are usually the largest bytes on the page. The rules that work: serve WebP (or AVIF) with a JPEG fallback — roughly 65–75% smaller than the originals; give every image explicit width and height so nothing shifts; load the first product images eagerly with fetchpriority="high" and everything below the fold lazily; and stop the theme from generating twelve unused image sizes for every upload.

Fonts: self-host, preload the one or two files above the fold, use font-display: swap with size-adjusted fallbacks so text does not jump when the web font arrives.

Step 7: the server underneath

No amount of code fixes an under-provisioned server. What we check: PHP 8.2+ with OPcache (and JIT) enabled, enough PHP workers for peak concurrency (roughly one worker per two to three concurrent visitors), MySQL/MariaDB with an InnoDB buffer pool sized to hold the working set, HTTP/2 or HTTP/3, and a CDN in front of static assets. Shared hosting that was fine for a brochure site is rarely fine for a store with 500 products and a Black Friday campaign.

What "fast" looks like when it is done

Metric	Typical slow store	After optimisation
Time to first byte (logged-in)	800–1,500 ms	under 300 ms
Mobile LCP (product page)	4–6 s	under 2 s
INP	300–600 ms	under 200 ms
Database queries per page	150–400	under 60
Checkout scripts loaded	40–70	under 20

These are the ranges we see across the stores we optimise; your starting point decides how far you move, and we publish before-and-after numbers for every engagement so you can see it.

What not to do

• Do not stack caching plugins — two page caches create more problems than one.
• Do not "optimise" by deleting scripts blindly; a broken add-to-cart button is worse than a slow one.
• Do not skip the measurement. Without field data you are optimising a lab score, and lab scores do not buy anything.
• Do not treat speed as a one-off. Every new plugin and theme update can undo it — schedule a check.

WPWooExperts are WooCommerce experts with 10+ years on the platform and 120+ published extensions. WordPress speed optimization is one of our core services: measured, engineering-led, with before-and-after numbers. If your store is slow, send us the URL and we will tell you what is causing it.

core web vitalswoocommerce expertswoocommerce performancewoocommerce speed