← All case studies Forensic Troubleshooting

The Weekend Crash

WooCommerce store, active marketing campaign, revenue in freefall

30s <1s

Add to Cart response time

847 23

Database queries per click

The situation

Over a critical sales weekend, a WooCommerce store's revenue had plummeted by 40%. A major marketing campaign was actively driving traffic to the site. Every second of delay was burning ad budget and losing customers who would not return.

The symptom was visible to every customer: clicking Add to Cart caused the button to hang for 25 to 30 seconds before responding. Most visitors gave up and left. The conversion rate had collapsed, but to anyone looking at the server dashboard, nothing appeared wrong.

The homepage loaded in under two seconds. The server CPU was calm. There were no error messages. The problem was invisible unless you looked in the right place.

The diagnosis

A single Add to Cart click was triggering 847 separate database queries. Most WooCommerce stores of comparable size generate 20 to 60 per page load. The database told the full story.

  • Abandoned cart plugin creating autoloaded bloat

    An abandoned cart recovery plugin had been aggressively saving every visitor's session data to the wp_options table — but never deleting it. Over time it had created 45,000 autoloaded rows. WordPress attempts to load every autoloaded row on every single page view, meaning the database was carrying the full weight of that accumulated data on every request.

  • wp_options table swollen to 2.3GB

    As a direct consequence, the wp_options table — which should be a few megabytes on a healthy site — had grown to 2.3GB. Every database operation that touched this table was suffering the overhead of scanning an object that had no business being that size.

  • Critical database index deleted by a previous developer

    A previous developer had attempted to repair the database and accidentally deleted a critical index in the process. Without it, the database had lost its ability to search its own data efficiently. What should have been indexed lookups were becoming full table scans.

The campaign was not the problem. The server was not the problem. Two specific, identifiable faults — one introduced by a plugin, one by a previous developer's botched repair — had compounded into a store that could not function under normal load.

The fix

Emergency triage was performed to stop the revenue loss immediately, with full remediation following once the site was stable.

  1. 1.

    40,000 redundant session records were deleted and autoloading was disabled on the remaining junk data. The wp_options table dropped from 2.3GB to 45MB.

  2. 2.

    The deleted database index was recreated, restoring the database's ability to perform efficient lookups. Query times on the affected operations fell immediately.

  3. 3.

    The abandoned cart plugin was removed and replaced with a lean alternative that stores session data correctly and cleans up after itself.

The outcome

Add to Cart response time dropped from 30 seconds to under one second. Database queries per click fell from 847 to 23. The marketing campaign was saved and conversion rates returned to normal within hours of the fix.

The damage had been building silently for months. The abandoned cart plugin had been accumulating session data unchecked since installation. The deleted database index had been degrading performance with every passing week. Neither fault was visible until the campaign weekend pushed the site beyond the point at which the compounding overhead could be absorbed.

A single bad plugin, left unchecked, can bring a profitable store to its knees. The damage accumulates silently — until a campaign weekend makes it impossible to ignore.

From the blog

Further reading

All articles →

Slow WooCommerce site costing you conversions?

I diagnose before I fix. You will know exactly what is wrong and what it will cost to resolve before any work begins.