Improving WooCommerce performance does not always require a full rebuild or a new hosting stack. In one WordPress cleanup project, the biggest gains came from removing unnecessary processing, simplifying legacy code, and making a few targeted changes to how the site handled product data, reviews, scheduled actions, CSS, and memory.
The work focused on stabilizing an existing WooCommerce site built with Divi. Rather than layering on more optimization plugins, the team first reduced avoidable server work and cleaned up redundant customizations. The result was a leaner admin experience, a more maintainable codebase, and a clearer foundation for future performance work.
Issue background
The WordPress admin area had become noticeably slower, particularly around WooCommerce product management and the Divi Visual Builder. The site had accumulated years of integrations, custom snippets, styling workarounds, and background processes, so the first phase focused on stabilization rather than a larger redesign.
The review identified several areas worth addressing:
- An unused Revenue Conduit integration was still generating failed scheduled actions.
- The WooCommerce Products list was loading excessive variation data just to display SKUs.
- Some mobile-header and product-grid CSS existed in more than one place.
- The WordPress memory configuration was lower than the server’s available capacity.
- Customer Reviews for WooCommerce (CusRev) was rebuilding review data on page views instead of reusing cached results.
- A suspected duplicate Facebook Pixel implementation needed verification.
- The active plugin stack needed a basic review for overlap and obsolete custom-code utilities.
The site already had several performance systems in place. Divi’s performance features were enabled, Imagify was handling image optimization, and the hosting environment already provided server-level page caching. WP Rocket was installed but disabled, so the team chose not to treat caching as part of this first cleanup phase.
Diagnosis
The WooCommerce Products screen contained one of the clearest admin-side bottlenecks. Custom SKU-display logic was loading every variation’s full data on each page load even though the screen only needed the SKU value. On a store with 274 variable products, that created unnecessary database and object-loading overhead.
The CSS review found that the same mobile-header and product-grid fixes were being loaded twice: once from the site’s stylesheet and again through inline theme code left over from earlier cache-related workarounds. The duplicate rules did not improve the layout, but they made future styling harder to audit.
Background processing also contained avoidable work. The Revenue Conduit service was no longer in use, yet failed scheduled actions had accumulated. One obsolete webhook alone had approximately 1,535 failed actions in the queue.
The CusRev implementation had another inefficiency: review data was being rebuilt on page views instead of cached per product. That increased repeated processing for information that did not need to be regenerated on every request.
The audit also corrected one suspected issue. The Facebook Pixel initially appeared to be installed twice, but closer review showed that it was a single implementation with correct deduplication. No Pixel change was required.
Resolution steps
The cleanup was first implemented and tested on staging, then approved changes were deployed to production.
- Optimize WooCommerce variation SKU lookup. The Products list logic was rewritten so it retrieved only the SKU data needed for display instead of loading each variation’s full data. The updated logic also cached the result. Variation SKUs were verified across all 274 variable products.
- Remove duplicate CSS. Redundant inline versions of the mobile-header and product-grid fixes were removed while the permanent rules in
style.csswere left intact. Archive and mobile layouts were compared against production to confirm there was no visual change. - Align the WordPress memory configuration. The WordPress memory limit was raised to better match the server’s available capacity and provide additional headroom for Divi’s Visual Builder.
- Cache CusRev review data per product. The review-loading logic was changed so product reviews could be reused instead of rebuilt on every page view. The team then verified that the reviews still rendered correctly.
- Clean up Revenue Conduit background activity. A cleanup tool was used to clear the backlog of failed scheduled actions associated with the retired integration. The remaining live cleanup included removing the dead Revenue Conduit webhooks and deactivating the no-longer-needed WooCommerce Legacy REST API plugin so the failed actions would not regenerate.
- Audit the Facebook Pixel implementation. The apparent duplicate was reviewed and confirmed to be one correctly deduplicated Pixel implementation, so no change was made.
- Review the plugin stack. The site had 32 active plugins, which was considered reasonable for an ecommerce site of its size. Most were clearly tied to payments, shipping, tax, SEO, or email. Two custom-code plugins, My Custom Functions and Simple Custom CSS and JS, were identified as cleanup candidates because their code was disabled or obsolete.
- Keep unrelated tools in place unless there is a reason to remove them. Zoho SalesIQ remained enabled because a final decision on live-chat usage had not been made.
- Defer caching strategy until layout direction is clear. Rather than re-enable WP Rocket immediately, the team separated caching and deeper performance tuning into a future task. Existing layout issues and the possibility of future design changes made it more sensible to stabilize the site first and tune caching afterward.
This sequencing mattered. Performance optimization is much easier to validate when the site’s layout, feature set, and custom code are stable. Tuning caches around a design that is about to change can create unnecessary retesting and duplicate work.
Final outcome
The approved cleanup work was deployed to production. The WooCommerce Products screen now used a lighter SKU lookup, duplicate CSS had been removed, WordPress memory was aligned more closely with server capacity, CusRev review data was cached per product, and obsolete Revenue Conduit processing had been cleaned up.
The work also made the codebase easier to reason about by separating confirmed problems from false positives. The suspected Facebook Pixel duplication did not require a fix, and the broader caching strategy was intentionally left for a separate performance phase rather than being changed without a clear need.
A later layout concern was reviewed and found to align with the site’s existing responsive breakpoint behavior rather than the cleanup deployment. The issue subsequently stopped occurring and no additional change was required.
The broader lesson is that WooCommerce optimization is often most effective when it starts with targeted server-side cleanup: reduce unnecessary object loading, cache repeatable data, remove obsolete integrations, eliminate duplicate custom code, and verify each suspected problem before changing it. Those steps can improve maintainability and admin responsiveness without forcing a full redesign.
If your WooCommerce admin is slow, Divi feels sluggish, or years of integrations and custom snippets have made your WordPress site difficult to maintain, contact Freshy. Our WordPress team can audit custom code, WooCommerce processing, plugins, scheduled actions, and performance bottlenecks.
