Mostafa Abouelwafa — Software Engineer

WordPress, Laravel, AI Agents & Automation

Portfolio — Case Study

Speed Optimization That Saved a Business

How I reduced a WooCommerce store’s database from 1.1 GB to 100 MB and cut page load from 60 seconds to under 1 second

Database Size 1.1 GB 100 MB 91% reduction
Page Load 30–60 s 0.8 s 98% faster
Uptime ~85% 99.9% crashes eliminated
Monthly Crashes 15+ 0 fully stable
The Problem

A WooCommerce Store on the Edge of Collapse

The client came to me after their hosting company told them they couldn’t help. Revenue was being lost during every crash window.

The situation: A WooCommerce store was crashing multiple times per day. Pages took 30–60 seconds to load when the site was up at all. The hosting company had run out of suggestions. Every hour of downtime meant lost sales and an increasingly desperate business owner.
🚫
Multiple crashes per day The store went down without warning throughout the day, sometimes staying offline for hours.
⏳
30–60 second page loads When the site was up, customers faced unbearable wait times — most bounced immediately.
😱
Hosting company gave up They had exhausted their suggestions. The client was told to “upgrade to a bigger server.”
📈
Revenue loss every crash Each downtime event directly impacted sales, customer trust, and the store’s search rankings.

Site Metrics at Time of Engagement

1.1 GB Database Size

Should be ~50 MB for a store this size. An 1,100% overrun.

316 MB Auto-loaded Data

Should be 2–5 MB. This data was loaded into memory on every single page request.

30–60 s Page Load Time

Often timing out entirely. Google’s threshold for abandonment is 3 seconds.

~85% Uptime

Frequent, unpredictable crashes. A healthy store should be 99.9%+.

Root Cause Analysis

The Diagnosis

I performed a full database and server audit before touching anything. Understanding the root cause prevents the same problem returning in three months.

1

Database Audit Revealed 1.2 Million Orphaned Transients

A thorough database audit uncovered 1,247,893 orphaned temporary records that should have been automatically cleaned up. Instead, they had been piling up for months with no maintenance in place, bloating the database from its expected ~50 MB to over 1.1 GB.

2

A Poorly Coded Import Plugin Was the Root Cause

A product import plugin was firing hooks on every product during each import run, creating a unique transient entry per product, per run, per currency variation. With 38 failed import attempts and thousands of products, this had exploded into over a million database rows.

3

316 MB of Data Loaded on Every Single Page View

WordPress pre-loads certain settings into memory on every page request. With 316 MB marked for pre-loading, the server was reading a third of a gigabyte before the page even started rendering. This was the direct cause of the timeouts and crashes under traffic.

4

No Caching, WP_DEBUG On, No Monitoring

Zero object caching meant every page load queried the database from scratch. WP_DEBUG was enabled on production, generating gigabytes of error logs that were consuming server disk. No alerting meant crashes went unnoticed until customers reported them.

Key Findings from the Database Audit

1,247,893 Orphaned Records

Temporary cached entries that were never cleaned up — clogging the database and slowing every page load.

316 MB Loaded on Every Page

The database was forced to read 316 MB of data before it could even start loading the actual page content.

38 Failed Import Runs

Each failed product import left behind thousands of junk records that were never cleaned up.

0 Cleanup Processes

No automated maintenance was in place — the database had been accumulating waste for months.

The Solution

A Three-Phase Fix

I structured the fix in three phases to address the immediate emergency first, then build lasting performance, then ensure the problem could never return.

1

Emergency Stabilization

Stop the bleeding immediately
  • Disabled the problematic import plugin that was generating transients on every hook fire
  • Purged 1,247,893 orphaned database records that had been accumulating for months
  • Database size dropped from 1.1 GB to 100 MB immediately — an 91% reduction in one operation
  • Site stabilized within minutes; page load times dropped from 60 seconds to under 5 seconds before any caching was added
2

Performance Optimization

Build a proper performance stack
  • Installed and configured Redis object cache — database queries now served from memory on repeat requests
  • Configured full-page caching, browser caching headers, and GZIP compression
  • Audited and optimized which data gets pre-loaded on every page; reduced from 316 MB to just 4 MB
  • Tuned MySQL settings: increased buffer pool size, enabled query cache, optimized slow query threshold
  • Moved WP-Cron from page-load-triggered to a real server-side cron job
3

Prevention

Ensure the problem cannot return
  • Configured automated transient cleanup via WP-Cron schedule — orphaned entries now pruned weekly
  • Disabled WP_DEBUG on production; implemented proper error logging to a size-capped log file
  • Set up uptime monitoring with SMS/email alerts so crashes are detected in seconds, not hours
  • Implemented a proper automated backup strategy with off-site storage
  • Documented the import process to prevent future transient storms during product updates
Results

Before vs. After

Every metric improved significantly. The store went from unstable and unusable to fast and reliable.

All improvements delivered within 48 hours
Database Size Total DB on disk
1.1 GB Before
100 MB ↓ 91% reduction
91% improvement
Auto-loaded Data Data loaded on every page request
316 MB Before
4 MB ↓ 99% reduction
99% improvement
Page Load Time Cached, real browser timing
30–60 s Before
0.8 s ↓ 98% faster
98% improvement
Uptime 30-day rolling average
~85% Before
99.9% ↑ Fully stable
Near-perfect uptime achieved
Monthly Crashes Full site outages per month
15+ Before
0 ↓ Eliminated
100% crash-free
91% Database size reduction
99% Autoload data eliminated
75x Faster page loads
0 Crashes post-fix
Technical Stack

Tools & Skills Used

A real performance fix requires reaching across multiple layers of the stack.

MySQL WP-CLI Redis Nginx Query Monitor Server Tuning PHP Profiling WooCommerce WordPress Internals Database Optimization Caching Architecture Uptime Monitoring

Is Your WordPress Site Slow?

I specialize in diagnosing and fixing WordPress performance issues. If your store is crashing, timing out, or just painfully slow, I’ll find the root cause and fix it properly.

Hire Me on Upwork →