WooCommerce slow? The 7 real causes — and what actually helps

"My WooCommerce is slow" is the most common complaint I hear from shop owners — and the worst-answered one. Google serves you 25-tips listicles, you install yet another caching plugin, compress a few images, and the shop still takes 4 seconds on a phone.
The problem: most lists treat symptoms in random order. In reality, slow WooCommerce shops almost always have one of seven causes — and those causes have a clear diagnostic order. Let's walk through them. No voodoo, just the numbers that matter.
Before you change anything: measure three numbers
Optimizing without measuring means swapping plugins blindfolded. You need exactly three values, all free to measure with PageSpeed Insights:
- TTFB (server response time) — how long your server needs to send the first byte. Target: under 0.4 s.
- Mobile LCP — when the main element of the page becomes visible. Google's threshold for "good": 2.5 s. Most WooCommerce shops sit at 3–5 s.
- Product page load time, not just the homepage. That's where your customers buy — and where WooCommerce is heaviest.
Why it matters: even one extra second of load time measurably costs conversions — Google/Deloitte research shows that improving load time by just 0.1 s can lift retail conversion rates by ~8 %. Page speed isn't developer vanity, it's revenue.
With those three numbers in mind — here are the causes, in the order you should check them.
Cause 1: Your hosting is too weak (you'll see it in TTFB)
If your TTFB is above 0.8 s, don't think about anything else until that's solved. WooCommerce runs PHP + MySQL on every page view — on an oversold $5 shared host, that will never be fast.
What helps: a proper managed WordPress or VPS plan (from ~$15–30/month), PHP 8.2+, a server close to your customers, Redis/object cache if available. This is the only item on this list that costs money instead of work — and with bad starting hosting, it's the single biggest lever.
What doesn't help: a caching plugin on top of broken hosting. That masks the homepage and leaves the cart and checkout just as sluggish as before.
Cause 2: Your database is bloated
The classic for shops that got slower over the years even though "nothing changed": autoloaded options, expired transients, action-scheduler logs, and orphaned sessions bloat the database — and every single page load drags it along.
I've covered the four sources and the exact cleanup queries in a dedicated guide: Cleaning up the WooCommerce database — the fix that halves your LCP. Costs nothing, takes an afternoon, and for affected shops often beats any plugin.
Cause 3: Your plugin stack loads on every click
The average WordPress site runs 21 plugins; WooCommerce shops usually more. Every plugin loads its PHP code on every page view — and many load their CSS/JS on pages that don't need it (the form builder on product pages, the slider in the checkout).
What helps: an inventory. Which 5 plugins cause the most load (Query Monitor will show you)? Which ones could be replaced by a few lines of code? The honest decision rule: Not every problem needs another plugin.
Cause 4: Your images are too big
Unspectacular, but on product pages often half the page weight: 2 MB JPEGs at 4000 px displayed as 300 px thumbnails.
What helps: WebP/AVIF instead of JPEG (saves 30–60 %), correct image sizes per use, lazy loading for everything below the fold — but not for the main image (that hurts LCP). Most optimization plugins handle this reliably.
Cause 5: Caching — helps, but not the way you think
Here's the uncomfortable truth no caching-plugin vendor tells you: page caching only goes so far with WooCommerce. Cart, checkout, and logged-in users must never be served from cache — exactly the pages where buying happens. And WooCommerce's "cart fragments" AJAX bypasses the cache once more on every page.
What helps: page cache for homepage/categories/blog (obviously), object cache (Redis) for the dynamic pages, disabling cart fragments if your theme tolerates it. What you need to know: a blog becomes "done-fast" through caching. A shop doesn't — its dynamic core stays as fast as PHP + database + hosting allow (see causes 1 and 2). Why the checkout suffers most from this pattern — and the 6 levers that work there: WooCommerce checkout slow?.
Cause 6: Theme and page builders carry dead weight
Multipurpose themes and page builders (Elementor, Divi & co.) are convenient — and expensive in load time: huge DOM trees, global CSS/JS on every page, nested render chains. A PSI audit shows it as "Reduce unused CSS/JS" and "Avoid excessive DOM size".
What helps: a lean theme (in a classic setup), builders only on landing pages instead of shop pages, disabling unused widgets/modules. Realistically you'll gain a few hundred milliseconds here — worth it, but it doesn't bend physics.
Cause 7: You've hit the architecture limit
And now the part the 25-tips lists leave out: if hosting, database, plugins, images, caching, and theme are all clean and your shop still sits at 2.5–4 s mobile LCP — you're no longer optimizing against mistakes, you're optimizing against the architecture. WordPress renders every shop page server-side on request, loads theme + plugins + jQuery legacy along with it, and on mobile 4G that adds up.
From here, there are two honest answers:
- Live with it. If your shop is a side channel: totally fine. A 3 s LCP is no tragedy if your revenue happens elsewhere.
- Replace the delivery, not the shop. A headless storefront (Next.js) sits in front of your existing WooCommerce: products, orders, admin — everything stays. Only what your customers see gets delivered differently — statically, in under a second. What that means in practice and what stays exactly the same, with real before/after numbers: Your WooCommerce shop is slow? You don't have to rebuild it.
The order as a checklist
| # | Check | Tool | Typical gain | |---|---|---|---| | 1 | TTFB > 0.8 s? → hosting | PageSpeed Insights | large (if affected) | | 2 | Database bloated? | autoload query | large on older shops | | 3 | Plugin inventory | Query Monitor | medium–large | | 4 | Images (format/size) | PSI "Opportunities" | medium | | 5 | Caching done right | cache plugin + Redis | medium (not in checkout) | | 6 | Theme/builder weight | PSI "Diagnostics" | small–medium | | 7 | Architecture limit reached? | LCP > 2.5 s despite 1–6 | headless: LCP < 1 s |
Work through the list top to bottom — not the other way around. Starting at 6 means polishing details on a broken foundation.
Where does your shop stand? Measure it in 30 seconds
I built a free WooCommerce speed check for exactly this: enter your shop URL and you get performance, LCP and more for mobile and desktop — measured with the same Google tooling as in this article, plus an honest assessment of which of the 7 causes your shop is stuck on.
Want the next performance and build guides — including all the pitfalls? Subscribe to the "Built with AI" newsletter.
Prefer done-for-you? Drop me a line — making slow WooCommerce shops fast is my day job.
Built with AI — the newsletter
Hands-on AI tutorials and the tools I actually use — straight to your inbox. Free, no hype.
Powered by Substack. Unsubscribe anytime.