Confidential WooCommerce performance recovery

Mariusz Szatkowski

Starting constraint

The store had a familiar WooCommerce shape: a working catalogue, a checkout that could not be broken, several marketing scripts, a theme with years of accumulated overrides, and mobile Core Web Vitals in the red on key templates.

The commercial risk was not theoretical. Any optimisation that touched cart, payment, stock, taxes, or session handling had to be staged behind measurement and rollback.

Diagnosis

The first pass separated template families: homepage, category, product, cart, checkout, and content pages. Each family had different performance constraints, so treating the site as one score would have hidden the real bottlenecks.

The biggest issues were cumulative: third-party scripts loading too early, unused CSS from legacy components, image sizing drift, cache misses on pages that could be safely cached, and uncached wc-ajax=get_refreshed_fragments cart refresh on every page load flooding PHP-FPM under concurrent traffic.

Architecture decision

The project did not start with a rewrite. The first decision was to protect checkout correctness, then move only safe surfaces toward stronger caching and lighter rendering.

Cloudflare handled edge rules, cache boundaries, redirects, bot filtering, and observability. WordPress and WooCommerce stayed the commercial source of truth. Front-end changes were scoped by template family, not by a generic theme cleanup promise.

Delivery model

Work was delivered in short batches: baseline, script audit, image and layout fixes, cache policy, checkout isolation, staging validation, production rollout, then post-launch measurement.

Every batch had a rollback path. That matters more than a dramatic launch when revenue flows through the same checkout being optimised.

Outcome bands

Performance was measured 30 days post-deployment on the confidential EU B2B store: LCP 5.4s to 1.8s (-66%), checkout TTFB 2.1s to 0.4s (-80%), main-thread blocking 1,200ms to 180ms (-85%), cart-to-checkout abandonment 42% to 34% (-19%).

The reusable lesson: performance recovery in WooCommerce is less about chasing a perfect score and more about choosing the right boundary between cacheable commercial pages and live transactional flows.

Frequently asked questions

How do I fix WooCommerce checkout lag on mobile without rebuilding the store?

Start with measurement on cart, checkout, and product templates, not a rewrite. On a confidential EU B2B store (12,000+ SKUs) we fixed mobile checkout lag by pruning 450,000+ autoloaded wp_options rows, stopping wc-ajax=get_refreshed_fragments on every page load, offloading 25+ marketing pixels to Cloudflare Zaraz, and adding Redis with checkout groups excluded. Checkout TTFB fell from 2.1s to 0.4s and LCP from 5.4s to 1.8s, with each batch staged and rolled back if payments drifted.

What causes slow WooCommerce cart fragments under high traffic?

The default mini-cart fires uncached wc-ajax=get_refreshed_fragments on every page load. Under concurrent traffic those AJAX calls flood the PHP-FPM pool, queue database connections, and add latency before checkout even starts. In this case study, dynamic fragment refresh plus wp_options bloat (2.1 GB, 450,000+ autoloaded rows) compounded the delay. Fix: disable automatic fragment refresh, update cart state only after add-to-cart (we used sessionStorage), and clean autoloaded options so each request starts lighter.

How can a WooCommerce store reduce checkout latency without breaking payments?

Treat checkout as uncacheable and isolate it before tuning catalog pages. Use Redis for transients and query output but exclude session and checkout cache groups so tax, stock, and ERP pricing stay accurate. Offload marketing scripts to the edge (Cloudflare Zaraz) instead of the browser main thread. Ship changes in small batches with staging parity and rollback; never cache pages when session cookies are present. Measured result: checkout TTFB 2.1s to 0.4s with stable payment behaviour across B2B invoicing sweeps.

Why is the client not named?

The contract prevents public naming, screenshots, traffic details, and some commercial identifiers. The measured performance deltas and engineering method are publishable and documented above.