Why WooCommerce stores slow down after a couple of years

A WooCommerce store slows down because of things that accumulate, not because one thing breaks. An overgrown database, plugins nobody uses any more, images uploaded straight off a phone, and a theme doing more work on every page load than it needs to. Most of it is fixable in a day, without changing how the shop looks.

Stores almost never launch slow. They get slow at about the two-year mark, which is roughly how long it takes for a busy shop to fill its own database with rubbish. Here is where the time actually goes, in the order I check it.

The database is usually the biggest single win

WooCommerce writes a great deal to the database and cleans up very little of it. On a store that has been trading a couple of years, the usual offenders are:

  • Expired transients: cached fragments that were supposed to be temporary. I regularly find tens of thousands of rows that expired years ago.
  • Customer sessions: the woocommerce_sessions table holds a row for every visitor who put something in a basket. It is meant to be pruned. It often is not.
  • Autoloaded options: every page load reads the autoloaded rows in wp_options. Plugins add to it and rarely tidy up when removed. Once that figure passes about a megabyte, every single page on the site pays for it.
  • Orphaned product and order meta: rows belonging to products and orders that no longer exist.

None of this is visible from the front end, which is exactly why it goes unnoticed for years. It is also the cheapest thing on this list to fix.

Plugins you stopped using are still running

Deactivating a plugin stops it running. Leaving it installed but active because you are not quite sure whether it does anything does not. A typical store I take over has somewhere between thirty and fifty active plugins, and the owner can account for perhaps half.

The ones that hurt most are those loading their scripts and styles on every page rather than only where they are needed. A product-page slider has no business loading on your checkout, but plenty of them do.

This has to be done on a copy of the site rather than the live one. Deactivating something load-bearing on a trading shop in the middle of the afternoon is a lesson you only need once.

Images, which everybody knows about and nobody fixes

A modern phone produces a photograph around four megabytes. Uploaded straight into a product gallery, that is what your customers download. Multiply it by eight images on a product page and the page is thirty megabytes before a single line of code has run.

The fix is unglamorous: resize on upload, compress, serve modern formats, and load images below the fold only when they are scrolled to. It is a solved problem and it stays solved once it is set up properly.

What does not usually help

Buying a bigger server. It is the first thing most hosts suggest, because it is the thing they sell. A faster server makes slow code finish slightly sooner, but you are paying monthly to carry a problem rather than remove it. Fix the database and the plugin load first, and a surprising number of stores then find the server they already had was fine.

Caching plugins have the same trap. Caching is worth having, but a cache in front of a bloated store hides the problem from you and not from Google, and it does nothing at all for logged-in customers or the checkout, which is the part that actually earns money.

Common questions

How much faster can an old WooCommerce store realistically get?

It depends entirely on what is wrong, and anyone quoting you a percentage before looking is guessing. What I can say is that on a store that has never been cleaned, the database and plugin work usually produces the largest share of the improvement, and it is the cheapest part of the job.

Will any of this change how my shop looks?

It should not. Everything above is maintenance rather than redesign. If something does need to change visually, that is a conversation before it happens, not a surprise afterwards.

Can I do this myself?

Some of it. Image compression and removing plugins you know you do not use are reasonable to take on. Database work is where people get hurt, because the tools that clean it will also happily delete something important. Take a backup you have actually tested restoring before you start.

Does a care plan cover this kind of work?

Speed and database optimisation is included from the Professional plan upwards, and the Commerce plan adds WooCommerce-specific health checks on renewals, payment gateways and failed transactions. On a store, those are the things worth watching continuously rather than once a year.

If your store has got slower

Send me the address and I will run it through the same audit I use on the sites I look after, and tell you what it finds. That costs nothing, and it is the honest way to work out whether there is a day’s work here or a fortnight’s. Get in touch, or read about care plans if you would rather this never happened again.


Need a hand with your site?

Talk directly to the developer who’ll do the work. No account managers, no hand-offs.

Previous
Next