WooCommerce speed: what to fix first

What the data shows

The 2025 Web Almanac's ecommerce chapter compares platforms using real-visitor data. It counts a site as good only when it passes all three Core Web Vitals. These are the mobile results for the largest platforms:

On desktop the pattern is the same: 33% of WooCommerce stores pass, against 76% for Shopify. The Lighthouse medians tell the same story in the lab. On mobile, the median performance score was 38 for WooCommerce stores and 55 for Shopify.

Read this carefully:

• It is a platform-wide pattern. It says nothing about your store. The Almanac says the gap is not destiny: self-hosted and heavily customized stores can perform well when the engineering is disciplined.
• The platforms are different kinds of product. The Almanac groups Shopify as software as a service, where the platform controls the code and the hosting. WooCommerce is self-hosted, running on infrastructure that the merchant or an agency manages. A WooCommerce store's result therefore reflects its host, theme, plugins and images as much as WooCommerce.
• Loading is the weak spot. Interaction and layout stability are closer across platforms. The gap is mostly in Largest Contentful Paint, which is where the host, the cache and the images matter most.

What WooCommerce does by itself

These facts come from the WooCommerce source code.

It marks some pages as not cacheable

On the cart, checkout and account pages, WooCommerce defines the constants DONOTCACHEPAGE, DONOTCACHEOBJECT and DONOTCACHEDB, which many caching plugins respect, and it adds WordPress's no-cache headers. In the current code, it removes the no-store directive for visitors who are not logged in, so the browser's back/forward cache is not blocked. See the back/forward cache.

This is correct. A cached cart page would show one customer another's basket. Your job is to make sure the cache and the host respect it, and to keep those pages light.

It loads its files on every page

WooCommerce hooks into the standard script loading on every front-end page. In the version we read, it enqueues a global woocommerce script and three stylesheets: a layout sheet, a general sheet, and one for screens up to 768 pixels wide. If AJAX add-to-cart is on, it adds one more script. On a store, that is expected. On a blog post or an "about" page, it is cost without benefit. A developer can remove the styles with the woocommerce_enqueue_styles filter, or dequeue the script on pages that are not part of the store. Test the cart and checkout after any change.

It also loads more on specific pages:

• the cart script on the cart;
• the checkout script on the checkout, and the account scripts on the account pages;
• on product pages with a classic theme, scripts for the image zoom, the gallery slider and the lightbox, if the theme supports those gallery features.

It keeps customer sessions in the database

For shoppers, WooCommerce keeps a session in its own database table and sets a cookie. By default the session lasts two days, or a week for a logged-in customer. The code caps session lifetimes at 30 days and logs a warning when a site asks for more, because long sessions can cause performance problems and a very large session table. Leave the defaults unless you have a reason.

It can redirect the first visit

If the default customer address is set to the option that geolocates with page-caching support, WooCommerce redirects the visitor, with a 307 status, to the same page with a v query parameter that holds a hash of the location. This keeps cached pages correct for each location, and it adds a redirect to the first visit. Check the Network panel for it. If you do not need location-based prices or taxes before checkout, a simpler setting avoids the hop.

It offers dedicated order tables

WooCommerce can store orders in tables of their own instead of in the WordPress posts tables. Its settings call this "High-performance order storage" and mark it as recommended, and they offer a compatibility mode that keeps both in sync. Changing it affects plugins that read orders, so check that yours support it, test on a copy, and back up first.

The fixes that pay off first

1. A page cache that does the right thing

Shop, category and product pages are the same for most visitors, so a page cache helps a great deal. Check that:

• these pages are cached for visitors who are not logged in;
• the cart, checkout and account pages are not;
• a price or stock change clears the right pages;
• visitors with items in the cart still get correct pages. Ask your host or cache plugin how it handles them.

See WordPress caching for the layers, the checks and the mistakes to avoid.

2. A persistent object cache

A store runs many database queries for products, prices, taxes and sessions, and a lot of that is repeated. WordPress's Site Health suggests a persistent object cache for larger sites, and WooCommerce itself writes cart sessions to the object cache when one is present. Ask your host for Redis or Memcached. See WordPress caching.

3. A host that matches the store

Uncached pages, which include every cart and checkout, depend on the server's processor, memory and database. If those pages are slow even with a cache on the rest of the site, look at hosting before anything else.

4. Product images

Product pages are mostly pictures. The main product image is usually the Largest Contentful Paint element, and category pages show many thumbnails. Make sure the first image is not lazy-loaded, that every image has the right size for its slot, and that galleries do not load all their pictures at once. See WordPress images.

5. A light theme, and few plugins

A store needs more plugins than a blog: payments, shipping, taxes, email, reviews and search. Each adds files and queries. Audit them as in themes and plugins. Pay particular attention to the ones that load on every page: review widgets, chat, pop-ups, currency switchers and tracking. If you use a page builder, see page builders.

6. Trim the database

Stores generate sessions, orders, logs and transients. Look at the autoloaded options and the transients first. See database cleanup.

How to measure a store

• Test the main page types. Home, a category, a product, the cart and the checkout, on a phone profile. Use the median of several runs. See why scores change.
• Test as a logged-out visitor, and with an item in the cart. A test that always starts with an empty session misses the pages your customers see.
• Use real-visitor data when your store has enough traffic. The category and product pages are the ones to compare. See the Chrome UX Report.
• Watch the server response for the uncached pages separately. See server response time.

Mistakes to avoid

• Caching the cart, checkout or account pages. It shows one customer another customer's data.
• Turning on every optimization option. Features that delay or combine scripts can break the cart or checkout. Test the whole purchase, from the product to the confirmation, after each change.
• Optimizing only the home page. Customers land on products and categories.
• Dequeuing a script that a payment or shipping plugin needs. Check the checkout after each change.
• Running a store on the cheapest hosting. The pages that earn money are the ones that cannot be cached.

Check your own page

Run the free audit on a product page and on a category page. Open LCP request discovery, Improve image delivery and Reduce unused JavaScript. Then run it on the cart. If the product pages are slow and the cart is much faster, the pages are heavy. If the cart is also slow, the server is the first place to look.

Sources

• Ecommerce chapter, Web Almanac 2025: the platform types, the Core Web Vitals pass rates and the Lighthouse medians by platform.
• WooCommerce source code: class-wc-cache-helper.php, class-wc-frontend-scripts.php, class-wc-session-handler.php and the order storage settings in CustomOrdersTableController.php.
• WordPress core: Site Health: the suggestion to use a persistent object cache.