Why your WooCommerce store is slow, and what actually fixes it

<p>Most WooCommerce speed advice starts in the wrong place: install a caching plugin, tick some boxes, watch a score go up. Then the store still feels slow on a phone, and nobody can explain why.</p> <p>Here is what is actually happening under a slow WooCommerce store, in the order it usually matters.</p> <h2>First: know what you are being measured on</h2> <p>Google grades real visits, not your laptop. The three Core Web Vitals are:</p> <ul> <li><strong>LCP</strong> (Largest Contentful Paint) &mdash; good is 2.5 seconds or less</li> <li><strong>INP</strong> (Interaction to Next Paint) &mdash; good is 200 milliseconds or less</li> <li><strong>CLS</strong> (Cumulative Layout Shift) &mdash; good is 0.1 or less</li> </ul> <p>Two details matter more than the numbers. First, a site passes only if <strong>75% of real page views</strong> hit the threshold &mdash; so your fast desktop visits do not cancel out your slow mobile ones. Second, INP replaced First Input Delay in March 2024, and it is much harder to pass. FID only measured the delay before the browser started handling your first click. INP measures the whole thing, on every interaction, until the screen actually updates. Stores that quietly passed FID often fail INP.</p> <p>This is why a Lighthouse score of 95 and a failing Search Console report are not a contradiction. Lighthouse is one simulated load on a fast connection. Search Console reports what your customers experienced.</p> <h2>Cause 1: cart fragments, firing on every single page</h2> <p>This is the big one, and it is specific to WooCommerce.</p> <p>WooCommerce keeps the little cart total in your header up to date using an AJAX call &mdash; <code>wc-ajax=get_refreshed_fragments</code>. It fires <strong>on every page load</strong>, including for a visitor who has never added anything to the cart and is just reading your About page.</p> <p>That request cannot be cached, because its whole job is to return something personal. So every page view boots WordPress from scratch, loads the WooCommerce session, and queries the cart, just to tell a first-time visitor that their cart is empty. On cheap shared hosting, under real traffic, that alone can be the difference between a site that feels instant and one that does not.</p> <p>The fix is not simply "disable cart fragments", despite what a lot of blog posts say. If your theme relies on them for the mini-cart or an AJAX add-to-cart button, ripping them out breaks the buying experience &mdash; which is a strange way to make a shop faster. The right fix is to load them only where they are needed, and to make sure your theme degrades gracefully without them.</p> <h2>Cause 2: your cache plugin is not caching the pages that matter</h2> <p>WooCommerce is built on personalisation: cart contents, customer-specific pricing, session state. Full-page caching exists to serve every visitor the same HTML. Those two ideas are in direct conflict.</p> <p>So the cart, checkout and account pages are excluded from caching by default &mdash; correctly, because serving one customer another customer's cart would be a far worse problem than a slow page. What often happens next is that the cache plugin gets credit for the home page being fast, while the pages that actually convert stay slow and nobody looks.</p> <p>What helps here is caching that understands WooCommerce cookies, plus object caching so the uncacheable pages at least stop re-running the same database queries. What does not help is stacking three optimisation plugins that each think they own the cache.</p> <h2>Cause 3: autoloaded options</h2> <p>WordPress loads every option marked <em>autoload</em> on <strong>every single request</strong>, whether or not the page needs it. WooCommerce stores are unusually prone to this: transients, session data, and settings left behind by plugins that were deactivated years ago but never cleaned up.</p> <p>WordPress Site Health flags this once autoloaded options pass roughly 800&nbsp;KB. I have seen stores several times over that, dragging an invisible weight into every request including the ones that are supposed to be cached.</p> <p>This is unglamorous, takes about twenty minutes, and is often the cheapest win available.</p> <h2>Cause 4: scripts loaded everywhere, needed in one place</h2> <p>The contact form plugin loads its JavaScript on all 400 pages. The slider loads on pages with no slider. The reviews widget loads a third-party script that loads two more.</p> <p>Every one of these lengthens the main-thread work the browser has to finish before it can respond to a tap &mdash; which is exactly what INP measures. This is usually the single biggest cause of a failing INP on WooCommerce.</p> <h2>Cause 5: the hero image and the fonts</h2> <p>Your LCP element is almost always the first big image or heading. Which means LCP is usually decided by four things: whether that image is in a modern format, whether it is served at the size it is displayed, whether it has a priority hint so the browser fetches it early, and whether a web font is blocking the text from painting.</p> <p>Lazy-loading the hero image &mdash; something a lot of "optimisation" plugins do automatically, site-wide &mdash; makes LCP <em>worse</em>, because you have explicitly told the browser to deprioritise the one image that is being measured.</p> <h2>The order I work in</h2> <ol> <li><strong>Measure from field data first.</strong> Search Console and CrUX show what real visitors got. A lab score is a hypothesis, not a result.</li> <li><strong>Fix the server-side load</strong> &mdash; cart fragments, autoloaded options, object caching. These help every page at once.</li> <li><strong>Audit the scripts</strong> &mdash; what loads, on which pages, and what would break if it did not.</li> <li><strong>Then the front end</strong> &mdash; images, fonts, critical CSS, layout stability.</li> <li><strong>Re-measure, and wait.</strong> Field data is a 28-day rolling window, so the report will not move the next morning even if the site is genuinely faster.</li> </ol> <h2>How to tell whether you were sold a score or a store</h2> <p>Three questions worth asking anyone who offers to speed up your shop:</p> <ul> <li><em>Are you working from field data or a Lighthouse run?</em> If they have not asked for Search Console access, they are optimising for a number, not for your customers.</li> <li><em>What will you disable, and what breaks if you are wrong?</em> A good answer names specific plugins and specific risks. A bad answer is "nothing, it is completely safe".</li> <li><em>What score will I get?</em> The honest answer is that nobody can tell you before seeing the site, because a slice of it depends on your host and theme. Anyone promising a specific number sight unseen is guessing, and will get there by breaking something.</li> </ul> <p>Speed work on WooCommerce is not mysterious. It is mostly the unglamorous part &mdash; finding out what your store does on every request that it does not need to do, and stopping it &mdash; done in the right order and measured against what real customers actually experience.</p>