Introduction
When a WooCommerce site with multilingual support (WPML) and a feature-rich theme like Woodmart starts experiencing slow load times, the root cause isn’t always obvious. In this 5-part case study series, we’ll walk through a real-world performance optimisation project where we took a struggling e-commerce site from 20+ second response times down to under 4 seconds.
This first post covers the initial crisis: what went wrong during migration, and the critical bug fixes needed before we could even begin performance optimisation.
Series Overview:
Part 1: The Performance Crisis (You are here)
Part 2: Load Testing Strategy with K6
Part 3: Finding the Bottleneck
Part 4: The Optimisation Playbook
Part 5: Results & Lessons Learned
Our client’s WooCommerce site (newstage.adnart.com) was experiencing severe performance issues after migrating from shared hosting to a VPS. The symptoms were alarming:
- Pages taking 20-30 seconds to load
- Frequent timeout errors
- Shop filtering is completely broken under load
- Database “out of sync” errors appearing randomly
- User experience was essentially broken
The site wasn’t just slow – it was practically unusable.
- WooCommerce – E-commerce platform managing 1000+ products
- Woodmart Theme – Product-focused theme with advanced filtering
- WPML – Multilingual support for English/French
- Multiple plugins – Product filtering, caching, optimisation tools
- VPS hosting – 4 CPU, 16GB RAM (plenty of resources)
With good hardware, the problem clearly wasn’t infrastructure capacity. Something had gone wrong during the migration.
Phase 1: Emergency Bug Fixes
Before we could even begin performance optimisation, we had to fix critical issues that were preventing the site from functioning at all.
Issue 1: Database Corruption from MariaDB Version Mismatch
The first critical issue we encountered was database corruption caused by a MariaDB version mismatch during the migration.
What Happened: The shared hosting environment ran MariaDB 10.3, but the new VPS came with MariaDB 10.6. The database dump was created in the older version, but when imported into the newer version, subtle incompatibilities caused data corruption in several tables.
The Symptoms:
- “MySQL is out of sync” errors
- Random query failures
- Inconsistent data between related tables
- Foreign key constraint violations
The Solution:
We had to systematically repair the corrupted database:
- Exported data from each corrupted table individually
- Validated data integrity by comparing row counts and key relationships
- Re-imported data table by table, verifying each import
- Ran database repair commands on all tables
- Verified table integrity with CHECK TABLE and REPAIR TABLE commands
The Solution:
We had to systematically repair the corrupted database:
- Exported data from each corrupted table individually
- Validated data integrity by comparing row counts and key relationships
- Re-imported data table by table, verifying each import
- Ran database repair commands on all tables
- Verified table integrity with CHECK TABLE and REPAIR TABLE commands
[sql]
— Check all tables for corruption
CHECK TABLE wp_posts, wp_postmeta, wp_terms, wp_term_relationships;
— Repair corrupted tables
REPAIR TABLE wp_posts;
REPAIR TABLE wp_postmeta;
— Verify foreign key relationships
SELECT TABLE_NAME, CONSTRAINT_NAME
FROM information_schema.TABLE_CONSTRAINTS
WHERE CONSTRAINT_TYPE = ‘FOREIGN KEY’
AND TABLE_SCHEMA = DATABASE();
— Optimize all tables after repair
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_terms, wp_term_relationships;
[/sql]
This tedious process took several hours but was absolutely necessary. You cannot optimise performance on a corrupted database.
Issue 2: Insufficient Memory Allocation
The next problem was simpler but just as critical: the VPS was configured with default PHP memory limits that were far too low for a WooCommerce + Woodmart + WPML stack.
What We Found:
- PHP memory_limit: 128M (way too low)
- WordPress was hitting memory limits during:
- Product filtering queries
- WPML translation loading
- WooCommerce cart calculations
- Image processing
The Symptoms:
- “Allowed memory size exhausted” errors in logs
- Pages crashing mid-load
- Admin panel is becoming unresponsive
- Product pages failing to render
We increased WordPress memory allocation to appropriate levels for a production e-commerce site.
// Add to wp-config.php before “That’s all, stop editing!”
// Increase WordPress memory limits
define(‘WP_MEMORY_LIMIT’, ‘256M’);
define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);
// Optional: Increase admin memory separately
if (is_admin()) {
define(‘WP_MEMORY_LIMIT’, ‘512M’);
}
[/php]
Why These Numbers?
- 256M for frontend: Handles product pages, filtering, cart operations
- 512M for admin/backend: Handles bulk operations, imports, image processing
- For sites with 1000+ products and multilingual support, these are the minimum recommended values
Result: Memory-related crashes stopped immediately. This was a prerequisite for any performance optimisation work.
Issue 3: Woodmart Child Theme Misconfiguration
The Woodmart child theme wasn’t properly configured according to official documentation standards, causing layout issues and preventing proper theme updates.
What Was Wrong:
- Child theme functions.php was overriding parent functions incorrectly
- Missing proper parent theme stylesheet enqueuing
- Custom CSS wasn’t being loaded in the correct order
- Template files were copied instead of using child theme overrides
- Shop page layout was broken
- Product grids displayed incorrectly
- Mobile responsiveness issues
- Couldn’t update parent theme without breaking the site
The Solution:
We rebuilt the child theme following Woodmart’s official documentation:
Code Block:
get(‘Version’)
);
}
// Child theme customizations go below this line
// Do NOT copy parent theme functions – use hooks and filters instead
[/php]
Best Practices We Followed:
- Used hooks and filters instead of copying parent functions
- Properly enqueued stylesheets in the correct order
- Only overrode the necessary template files
- Kept the child theme minimal and maintainable
Result: Shop page layout was fixed, and the site became update-safe.
Issue 4: Plugin Conflicts and Debug Errors
The WordPress debug log revealed dozens of PHP warnings and notices from plugin conflicts.
Common Issues Found:
- Deprecated function calls
- Undefined array keys
- Incompatible plugin versions
- Conflicting jQuery libraries
The Solution:
We systematically:
- Updated all plugins to the latest versions
- Resolved compatibility issues between plugins
- Removed deprecated function calls
- Fixed PHP 8.3 compatibility issues in custom code
Code Block:
# Enable WordPress debugging to find issues
# Add to wp-config.php temporarily
# WP_DEBUG already defined, so we’ll update it
# Find and replace the existing define
[/bash]
Code Block:
[php]
// WordPress debugging configuration
// Add to wp-config.php for troubleshooting
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
define(‘SCRIPT_DEBUG’, true);
// Log errors to /wp-content/debug.log
ini_set(‘log_errors’, 1);
ini_set(‘error_log’, WP_CONTENT_DIR . ‘/debug.log’);
[/php]
Issue 5: Home Page Slider Rendering
A minor but visible issue: the home page slider wasn’t rendering correctly, showing broken layouts and inconsistent heights.
The Problem:
The slider container didn’t have a defined width, causing the JavaScript slider library to miscalculate dimensions.
The Solution:
We added explicit dimensions to the slider container:
Code Block:
/* Add to theme’s custom CSS or child theme style.css */
.home-slider-container {
width: 100%;
max-width: 1920px;
height: auto;
margin: 0 auto;
}
.home-slider-container .slider-item {
width: 100%;
min-height: 600px;
}
/* Ensure responsive behavior */
@media (max-width: 768px) {
.home-slider-container .slider-item {
min-height: 400px;
}
}
[/css]
Emergency Fixes Complete: What We Learned
After several days of emergency bug fixes, the site was finally stable and functional. But it was still painfully slow.
Key Takeaways from Phase 1:
- Migration isn’t just “move files and database” – Version mismatches can cause subtle corruption that only appears under load
- Default PHP settings are rarely sufficient for production WooCommerce sites – Always configure memory limits appropriately
- Child themes must be built correctly – Following official documentation prevents a cascade of issues
- Debug everything before optimising – You can’t optimise a broken site
- Document everything – We created a detailed log of every change, which proved invaluable later
The Site Status After Bug Fixes
With all critical bugs resolved, here’s where the site stood:
✅ Fixed:
- Database corruption resolved
- Memory allocation sufficient
- Child theme properly configured
- All plugin conflicts resolved
- Slider rendering correctly
- No more PHP errors in logs
❌ Still Problematic:
- Pages taking 15-20+ seconds to load
- Shop filtering is extremely slow
- Timeouts under even moderate traffic
- Unknown performance bottlenecks
The site was functional, but the user experience was terrible.
What’s Next?
With the site stable, we could finally focus on performance optimisation. But first, we needed to understand exactly what was slow and why.
In Part 2 of this series, we’ll cover:
- Setting up comprehensive load testing with Grafana K6
- Creating realistic test scenarios for an e-commerce site
- Running tests with 5, 10, 20, and 40 concurrent users
- Discovering the “double-slash bug” that was doubling our load
- Initial shocking test results
The journey from 20 seconds to under 4 seconds starts with measurement.
👉 Continue to Part 2: Load Testing Strategy with K6
About This Series
This is Part 1 of our 5-part case study on WooCommerce performance optimisation:
✅ Part 1: The Performance Crisis (You just read this)
Part 2: Load Testing Strategy with K6
Part 3: Finding the Bottleneck
Part 4: The Optimisation Playbook
Part 5: Results & Lessons Learned
Have you experienced similar issues after a WordPress migration? Share your story in the comments below!
