Why is a WordPress web store slow, and how much can it be sped up?
Where does the slowness come from?
1. The amount of code to be loaded
A typical WooCommerce web store loads dozens of stylesheets and scripts: the theme's, the page builder's, every plugin's. Most of these aren't even used on the given page — but they get downloaded, processed and executed.
This is the part the visitor feels in the very first second: the page's outline is already visible, but it can't yet be clicked.
2. The number of database queries
Product listing in WooCommerce is not a single query. Every product involves price, stock, variants, tax, image, category, possibly customer-group-specific pricing — and the plugins add their share too. A category page showing 24 products easily runs several hundred queries.
This is the part that makes the server's response itself slow (high TTFB), and image optimization doesn't help with that at all.
3. The pages that cannot be cached
Caching works by storing a ready-made version of the page and serving that to the next visitor. This works great on the homepage and product pages. It does not work, however, where the page is different for every visitor: cart, checkout, account, a logged-in wholesale customer with their own prices.
In other words, it doesn't help precisely on the pages where money is made.
What does caching solve, and what doesn't it?
| Problem | Does caching help? | Why |
|---|---|---|
| Slow homepage, category page | Yes, a lot | The ready-made version of the page can be served |
| Large, uncompressed images | No, but image optimization does | Separate problem, separate tool |
| Many plugins' scripts and stylesheets | Partially | Less to compute, but just as much to download |
| Slow cart and checkout | No | Different for every visitor, cannot be saved |
| Slow admin interface | No | Caching serves the public pages |
| Customer group pricing | No | Same page, different prices — cannot be cached |
How far can it be sped up? The realistic order
- Measure, don't guess. PageSpeed Insights and server-side response time (TTFB) are to be looked at separately. If TTFB is high, client-side optimization won't help.
- Images. Modern format, correct size, lazy loading. The cheapest, fastest-paying-back step.
- Plugin inventory. For each plugin the question is: what does it add, and how much does it cost in milliseconds? The most common outcome is that three or four can be discarded.
- Cache and compression. From here on, the public pages will be fast.
- Database and hosting. If you've made it this far and the cart is still slow, the problem is structural.
Steps 1–4 bring noticeable improvement at most shops, and take a few days of work. At step 5 you have to decide whether to patch or rebuild.
When is it better to rebuild instead?
It's not a speed figure that decides, but a structural sign. Rebuild if:
- the checkout is slow, and caching by definition doesn't help with that;
- there is per-customer pricing or wholesale logic in the shop that makes every page unique;
- running the shop takes five or more paid plugins, kept alive by aligning them with one another;
- after every update something breaks, and you've already priced that into your monthly costs;
- the daily working hours spent in the admin interface are greater than what is justified relative to revenue.
In that case the question is no longer speed, but whether the system is fit for what you're doing with it. That's what custom web store development is about, and here I walk you through choosing a system: Shopify, WooCommerce or custom.
What does “fast” mean concretely?
When it comes to speed, a slogan is worth nothing — measurement is needed. That's why I measure my own sites and my reference sites daily, with the same command, and the results are published on the homepage and under references. Anyone can repeat this — that's the point.
Frequently asked questions
Will better hosting solve it?
Rarely on its own. Better hosting reduces server-side time, but not the amount of code to load or the number of queries. If query count is the problem, you're buying more expensive hardware for the very same problem.
How long does it take to speed up an existing shop?
Measurement plus the images–plugins–cache round typically takes a few days. This is the step with the best value for money, and it's worth starting with it before anyone starts talking about a new system.
Is the shop down during the rebuild?
No. The new system is built in parallel, and the switchover happens at a pre-agreed time, with redirects — so that existing search engine positions aren't lost either.