Your store felt fast when it launched. Now product pages take five seconds, your phone shows a white screen while the homepage "loads", and you have a suspicion your customers are not waiting around to find out what happens next.
They are not. Roughly half of shoppers abandon a page that takes more than three seconds. On mobile, where most of your traffic lives, it is worse.
Here is the uncomfortable truth we have to break to store owners in almost every audit: WooCommerce is rarely the problem. WooCommerce is a lean plugin on top of WordPress. What makes stores slow is what got installed around it. Below are the seven causes we find over and over, in the order we usually find them, with a way to check each one yourself in a few minutes.
1. A "premium" multipurpose theme doing too much
The most common single cause. Marketplace themes that promise 40 demo layouts and every feature imaginable ship the code for all of it on every page load, whether you use it or not.
We recently audited a beautiful handloom store with premium products and real craftsmanship behind it. The homepage shipped 59 separate scripts and 41 stylesheets. The theme, its page builder, and a slider plugin were each loading their own animation libraries. On a mid-range phone the page did not just load slowly, it briefly froze the browser.
Check it yourself: open your homepage, press F12, open the Network tab, and reload. Count the requests. A healthy store homepage makes 30 to 50 requests. If you see 150 or more, your theme stack is the first suspect.
The fix: you usually cannot slim these themes down meaningfully, because the weight is structural. The real fix is a rebuild on a lean theme, which sounds drastic but typically takes days, not months, and keeps all your products, orders and customers intact.
2. Page builders stacked on page builders
Elementor, WPBakery, Divi and friends let non-developers build layouts, and for a content site that trade-off can be fine. On a store, every builder in the stack adds its own CSS framework, its own JavaScript, and its own database queries, on every single page, including your checkout.
The stores that hurt most are the ones where a theme has a built-in builder, an agency added Elementor on top, and a slider plugin came bundled with the theme. Three rendering systems, one page.
Check it yourself: in your WordPress admin, look at Plugins. If you see two or more of: Elementor, WPBakery, Slider Revolution, Divi Builder, you are paying the stacked-builder tax.
The fix: pick one system, rebuild key templates in it, remove the rest. Product and checkout pages should use almost no builder markup at all.
3. Images uploaded straight from the camera
Product photography matters, and it is also the heaviest thing on your site. A 4000 pixel photo saved as a 3 MB JPEG, displayed in a 400 pixel grid tile, wastes 90 percent of what the customer downloaded.
Check it yourself: right-click a product image on your shop page, open it in a new tab, and look at the URL and dimensions. If you see original camera files being served in grid layouts, this is costing you seconds per page.
The fix: serve images in WebP, sized to their display containers, lazy-loaded below the fold. This is one of the highest-return fixes because it needs no redesign: an image pipeline plugin plus one bulk-conversion pass usually cuts total page weight by half or more.
4. Hosting that was never meant for a store
A brochure site gets visited, cached, and served. A store is different: carts, sessions, stock checks and checkouts are dynamic and hit the server every time. The $5-a-month shared hosting plan that served your launch traffic fine will fall over exactly when you least want it to, during a sale.
Check it yourself: look at your Time To First Byte in the same Network tab (the first request, usually your domain). Consistently above 800 ms means the server itself is slow before a single image starts downloading. Under 400 ms is where you want to be.
The fix: managed WordPress or WooCommerce hosting with server-level caching, PHP 8.2 or newer, and a CDN in front. This is usually a $25 to $60 per month decision that outperforms weeks of code tweaking.
5. No caching strategy, or the wrong one
Caching is the difference between building each page from scratch for every visitor and handing out ready-made copies. Stores need a nuanced setup: catalog pages should cache aggressively, while carts and checkout must never be cached. Get it backwards and you either stay slow or, worse, show one customer another customer's cart.
Check it yourself: reload your homepage twice and compare load times in the Network tab. If the second load is not dramatically faster, nothing is being cached.
The fix: a well-configured cache plugin or, better, server-level caching from your host, with WooCommerce-aware exclusions for cart, checkout and account pages, plus an edge CDN for static assets.
6. Plugin sprawl, especially the "small" ones
Every plugin is a promise to run code on your site forever. Stores accumulate them: a wishlist here, a popup there, three SEO helpers, a table plugin someone used once in 2023. Individually harmless, together they add database queries, scripts and conflict risk to every page view.
Check it yourself: count your active plugins. There is no magic number, but a focused store runs 15 to 25. If you are past 40, some of them are dead weight, and one or two are probably responsible for a surprising share of your load time.
The fix: a plugin audit. Measure, do not guess: profile which plugins add the most load time, remove what nothing depends on, and replace heavy plugins with lighter equivalents or a few lines of custom code.
7. A database that remembers everything
WooCommerce stores write a lot: orders, sessions, logs, and thousands of post revisions. After a couple of years, the tables that power "is this in stock" queries are dragging around years of expired sessions and abandoned metadata. Product pages with large catalogs and layered filters feel it first.
Check it yourself: this one is hard to see from the outside, which is honestly why it survives so long. Slow category pages with filters, on a site where everything else checks out, are the classic symptom.
The fix: scheduled database cleanup, autoload audit, and indexes appropriate to your catalog size. On large catalogs this is where the biggest single-query wins hide.
The pattern behind all seven
Notice what is not on this list: WooCommerce itself, and WordPress itself. In our audits the platform is almost never the bottleneck. The bottleneck is accumulated decisions, each reasonable at the time, that nobody ever measured.
That is also why "make it faster" projects fail when they start with tweaks. The order matters: measure first, fix the structural causes (theme, builders, hosting), then the content causes (images, plugins, database). Doing it backwards means optimizing images that a broken theme will bury anyway.
Fix it yourself, or get the numbers first
Everything above is checkable with free tools and an honest hour. If you would rather have the numbers handed to you: our store audit measures all seven causes on your actual store, tells you which two or three are costing you sales, and gives you a prioritized fix plan with effort estimates. It is a fixed price, and if you go ahead with the fixes, the audit fee is credited toward the work.
Frequently asked questions
How fast should a WooCommerce store be? Under 2.5 seconds for the Largest Contentful Paint on mobile, which is Google's own "good" threshold. Under 2 seconds, conversion impact from speed largely disappears. Most stores we first audit sit between 5 and 9 seconds on a mid-range phone.
Will a caching plugin alone fix my slow store? It helps, and it is rarely enough. Caching speeds up repeat views of cacheable pages, but it cannot fix a heavy theme, oversized images, or slow hosting, and it must be configured to exclude cart and checkout. Think of it as one of the seven fixes, not the fix.
Should I switch from WooCommerce to Shopify because of speed? Not for speed alone. A well-built WooCommerce store on decent hosting is fast. Shopify removes the hosting and caching burden from you, which is valuable for other reasons, but migrating to escape a bloated theme means paying migration costs to solve a problem a rebuild would solve cheaper. We build on both, and we will tell you honestly which fits your situation.
How long does it take to fix a slow store? Images, caching and hosting moves: days. A theme rebuild: one to three weeks depending on the store. The audit exists so you spend those weeks on the causes that matter for your store, not a generic checklist.