Store Rebuilds & Refactoring

When to Rebuild vs Optimize

Not every slow WooCommerce store needs a full rebuild. Some stores just need targeted optimization: caching configuration, image compression, plugin pruning. But there are clear signals that a rebuild is the right move.

Rebuild when:

• Your store uses a page builder (Elementor, Divi, WPBakery) on product and checkout pages
• The wp_options table has more than 2MB of autoloaded data
• You have more than 40 active plugins
• Your theme loads jQuery, multiple CSS frameworks, or its own JavaScript runtime
• Server response time (TTFB) exceeds 500ms with caching enabled
• You’ve outgrown shared hosting but performance hasn’t improved on managed hosting

Optimize when:

• The store is already on a block theme or lightweight classic theme
• Performance issues are isolated to specific pages
• Plugin count is under 25 and you know what each one does
• The database is under 500MB and hasn’t been running for more than 2 years

The Page Builder Problem

Page builders are the single biggest source of WooCommerce performance problems. Here’s why.

A typical Elementor installation adds 400-800KB of CSS and 200-400KB of JavaScript to every page load. This happens even on pages built with the default WordPress editor. The builder’s runtime, widget registry, and responsive framework load globally.

Multiply this across WooCommerce’s template hierarchy (shop, product, cart, checkout, my account) and you’re serving megabytes of unused code to every customer.

The Real Cost

• Largest Contentful Paint increases by 1-3 seconds
• Total Blocking Time can exceed 500ms from builder JavaScript alone
• Cumulative Layout Shift suffers from dynamically injected elements
• Server response time increases because the builder runs PHP on every render

Migration Path

The migration from page builder to Gutenberg blocks follows a predictable pattern:

1. Audit - Document every page builder template and its content
2. Map - Identify which builder widgets map to native blocks or custom blocks
3. Build - Create custom blocks (ACF Pro) for anything without a native equivalent
4. Migrate - Move content page by page, starting with the highest-traffic templates
5. Test - Verify functionality, especially WooCommerce checkout and cart

Database Cleanup

Every WooCommerce store accumulates database bloat. The longer it runs, the worse it gets.

Common Sources of Bloat

Post revisions - WordPress saves every edit as a revision. A 3-year-old store can have 50,000+ revisions consuming hundreds of megabytes.

Transients - Expired transients sit in the options table until something cleans them up. Many plugins never clean up after themselves.

WooCommerce sessions - The woocommerce_sessions table grows unbounded on high-traffic stores.

Orphaned postmeta - When products or orders are deleted, their metadata often stays behind.

Action Scheduler - WooCommerce’s background job runner accumulates completed action logs indefinitely.

The Options Table

The wp_options table is the most critical performance target. Every autoloaded row is pulled into memory on every single page load. A healthy store keeps autoloaded data under 1MB. We’ve seen stores with 15MB+ of autoloaded data.

Common autoload offenders:

• Plugin settings stored as serialized arrays
• Cache plugin data that should be in object cache
• SEO plugin sitemaps stored in options
• Theme customizer settings with embedded media

Infrastructure Setup

After the rebuild, the store needs infrastructure that matches its new performance characteristics.

Recommended Stack

• NGINX as the web server and reverse proxy
• PHP 8.2+ with OPcache properly configured
• MariaDB 10.6+ with tuned buffer pool and query cache
• Redis for object cache (via Object Cache Pro)
• CDN for static assets (Cloudflare, Bunny, or Fastly)

Server Sizing

A WooCommerce store doing 1,000-10,000 orders/month typically runs well on:

• 4 CPU cores
• 8GB RAM
• NVMe SSD storage
• Dedicated (not shared) resources

Caching Layers

A properly cached WooCommerce store has four caching layers:

1. CDN edge cache - Static assets and full-page cache for logged-out visitors
2. NGINX FastCGI cache - Server-level full-page cache
3. Redis object cache - WordPress database query cache
4. PHP OPcache - Compiled PHP bytecode cache

Post-Migration Checklist

After migration, verify everything works:

• All products display correctly with variations and gallery
• Cart add/update/remove functions properly
• Checkout completes with payment processing
• Order confirmation emails send
• Customer account pages load (orders, addresses, downloads)
• Search returns accurate results
• 301 redirects cover all changed URLs
• Google Search Console shows no new crawl errors
• Core Web Vitals pass in Google PageSpeed Insights
• Analytics tracking fires on all key events