WooCommerce Performance Crisis: How Migration Led to 20-Second Load Times

When a WooCommerce site with multilingual support and a feature-rich theme starts hitting 20-second load times, the root cause is rarely obvious. This is Part 1 of a 5-part case study where we took a struggling e-commerce site from 20+ second response times down to under 4 seconds.

The initial problem

Our client’s WooCommerce site was experiencing severe performance issues after migrating from shared hosting to a VPS. Despite having 4 CPU cores and 16GB RAM — more than enough — the symptoms were alarming:

• Pages taking 20–30 seconds to load
• Frequent timeout errors under any real traffic
• Shop filtering completely broken under load
• Database “out of sync” errors appearing randomly
• User experience essentially broken

The stack: WooCommerce managing 1,000+ products, Woodmart theme with advanced filtering, WPML for English/French multilingual support, and multiple plugins. With good hardware, the problem clearly wasn’t infrastructure capacity. Something had gone wrong during migration.

Phase 1: Emergency bug fixes

Issue 1 — Database corruption from MariaDB version mismatch

The shared hosting ran MariaDB 10.3, but the new VPS came with MariaDB 10.6. The database dump was created in the older version, and when imported into the newer version, subtle incompatibilities caused data corruption in several tables — producing “MySQL is out of sync” errors, random query failures, and foreign key constraint violations.

We had to systematically repair the corrupted database table by table:

-- 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;

-- Optimize all tables after repair
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_terms, wp_term_relationships;

Issue 2 — Insufficient PHP memory allocation

The VPS was configured with default PHP memory limits — 128M — far too low for a WooCommerce + Woodmart + WPML stack. WordPress was hitting memory limits during product filtering queries, WPML translation loading, and cart calculations. Pages were crashing mid-load.

// Add to wp-config.php before "That's all, stop editing!"
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// Increase admin memory for bulk operations
if (is_admin()) {
    define('WP_MEMORY_LIMIT', '512M');
}

256M for the frontend handles product pages, filtering, and cart. 512M for admin handles bulk imports and image processing. For sites with 1,000+ products and multilingual support, these are the minimum recommended values. Memory-related crashes stopped immediately after this change.

Issue 3 — Woodmart child theme misconfiguration

The child theme wasn’t properly configured per Woodmart’s official documentation. It was overriding parent functions incorrectly, causing shop layout breaks, product grid display issues, and making it impossible to update the parent theme without breaking the site.

// Correct Woodmart child theme enqueue
add_action('wp_enqueue_scripts', 'woodmart_child_enqueue_styles', 1000);

function woodmart_child_enqueue_styles() {
    wp_enqueue_style('woodmart-style',
        get_template_directory_uri() . '/style.css'
    );
    wp_enqueue_style('woodmart-child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array('woodmart-style'),
        wp_get_theme()->get('Version')
    );
}

Key rule: use hooks and filters instead of copying parent functions. Only override the template files you actually need to change. After the rebuild, the shop layout was fixed and the site became update-safe.

Issue 4 — Plugin conflicts and debug errors

The WordPress debug log showed dozens of PHP warnings and notices — deprecated function calls, undefined array keys, incompatible plugin versions, conflicting jQuery libraries. We enabled proper debugging, resolved all conflicts, and updated everything to the latest compatible versions.

// Temporary debugging — add to wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
ini_set('error_log', WP_CONTENT_DIR . '/debug.log');

Issue 5 — Homepage slider rendering

The slider container had no defined width, causing the JavaScript library to miscalculate dimensions and produce broken layouts with inconsistent heights.

.home-slider-container {
    width: 100%;
    max-width: 1920px;
    height: auto;
    margin: 0 auto;
}
.home-slider-container .slider-item {
    width: 100%;
    min-height: 600px;
}
@media (max-width: 768px) {
    .home-slider-container .slider-item {
        min-height: 400px;
    }
}

Where things stood after Phase 1

The site was functional, but the user experience was still terrible. With the bugs cleared, we could finally focus on understanding what was slow and why — which is exactly what Part 2 covers.

Key takeaways from Phase 1