Whenever a store owner tells me their WooCommerce site is slow, the first thing they blame is the theme. Nine times out of ten, the theme is fine. The time is going somewhere else, and until you know where, buying a faster theme or another cache plugin is just guessing.
Here’s where it actually goes on most stores, roughly in the order I check.
1. The server response (TTFB)
Before a single image loads, the browser waits for the server to build the page. On a slow WooCommerce store that wait is often 800ms to two seconds on its own — and no amount of front-end tuning fixes it. Usually it’s cheap shared hosting, a missing object cache (Redis), or PHP that’s building the whole page fresh on every request because full-page caching isn’t working for logged-in or cart sessions.
2. The database
WooCommerce is database-heavy, and two things quietly rot over time: an autoloaded options table that’s grown to megabytes (every plugin dumps data there, and half of them never clean up), and slow queries from search, filters or reporting. Stores that have been running for years are usually carrying a lot of this weight. A slow-query log tells you in minutes what a dozen plugins can’t.
3. Cart fragments
Open your network tab and reload any page. See a request to admin-ajax.php? That’s WooCommerce’s cart fragments running on every page, not just the cart — and it can’t be cached because it’s a POST tied to the session. On a busy server it adds 200–500ms across the whole site. It’s one of the most common wins, and I wrote up how to fix it properly in the cart fragments problem.
4. Third-party scripts
Chat widgets, analytics, ad pixels, review embeds — each one is a request to someone else’s server, and they block rendering while they load. I regularly see stores where the store’s own code is fast and 60% of the load time is other people’s JavaScript. You don’t always have to remove them, but they need to load in the right order and out of the critical path.
5. The front-end (yes, sometimes the theme)
Oversized hero images, render-blocking CSS and JS, fonts that block text from painting. This is the part everyone starts with, and it matters — but it’s usually the smallest slice of a slow store, not the biggest.
How to actually find your bottleneck
Don’t guess. Two tools tell you almost everything:
- A waterfall (your browser’s network tab, or WebPageTest) shows you the TTFB wait and exactly which requests are slow.
- Query Monitor (a free plugin) shows you slow database queries and which plugin fired them.
Between those two you’ll usually find that the “slow theme” was responsible for a fraction of the problem, and the real weight was the server, the database and cart fragments. Fix those in order of impact and the store gets fast — often dramatically — without touching the design. If you want the priority order for the Google metrics specifically, I broke that down in Core Web Vitals for WooCommerce.
If you’d rather not dig through waterfalls yourself, that’s exactly what a performance engagement is for — or start with a store audit and I’ll tell you where your time is actually going, ranked by what each fix is worth.