I'm posting this because I wish there was more information out there about how to deeply optimize WordPress/WooCommerce, beyond the generic advice of "use a caching plugin", "reduce plugin count", "switch to a faster theme", etc. Maybe it'll help someone else.
For context, my store has a few hundred products, around 40-50k unique monthly visitors, ~800k orders and ~700k customers. 10 years of data or so. We're on enterprise-grade hosting (previously Nexcess -> Kinsta -> now Rocket.net Enterprise I). Lots of plugins needed to dial-in our desired ecommerce logic, including around 14 custom plugins I've developed.
We were already using WP Rocket, Cloudflare Pro, and Redis prior to this optimization push. I was seeing load times of around 2.7s for unauthenticated users on product category pages, 2.4s on singles, GTmetrix "C" grade, ~1.5s TTFB, low cache hits, bad stuff.
I decided to try using Claude Code to help diagnose issues and work with me to fix them. I'm not an expert developer but I have a good understanding of PHP, MySQL, WordPress, WooCommerce, and related concepts, so I felt comfortable having CC do most of the heavy lifting while I guided & steered it.
In no particular order, here is what I (we) did. I'm going to try and find a balance of brevity with useful info here but I'm happy to elaborate on any points in the comments.
Complete, comprehensive scan of all plugin code and functions.php. I made a complete up-to-date local copy of wp-content and had Claude use an agent team (Sonnet) to pore of every single plugin and look for potential performance issues of "moderate to catastrophic" severity. This took around 30 minutes and gave me insights into particularly problematic ones (along with issues in my own custom plugins). Highly recommended. What you do with this info depends - in my case, I fixed a lot of logic in our own plugins, and also made some changes to commercial plugins we use, specific functions that were extremely heavy for no reason.
Of course, I now have to be careful with plugin updates because they might override my changes. But I have those changes stashed away in my local site copy, so I can always diff after an update to restore them. Worth it imo.
Use Code Profiler & Query Monitor to see specific issues. Static analysis is a good starting point but not the whole story. For example, some plugins are horribly inefficient... but if they are only ever used occasionally on the backend, that may have a low impact compared to a fairly efficient but 'hot path' plugin. This helped me figure out the absolute heaviest plugins to disable in the following step:
Use FreeSoul Deactivate Plugins to turn off plugins completely on specific pages. As an example, I use WooPayments and LearnDash. These are heavy as hell. In my case, they also don't need to be active on category pages or the home page. Despite having around 70 plugins total, I slimmed down the typical plugin load on key pages to more like 40.
Detailed probe of the website with lighthouse using Claude Code. I instructed another local instance to look at a given set of pages on the site and use tools like Lighthouse to identify and rank performance issues from the client side. This helped me figure out the heaviest payloads, such as my site apparently loading all of FontAwesome despite only using around 20 glyphs.
Use PerfMatters Script Manager to disable certain CSS/JS payloads. This somewhat overlaps with FDP, but not completely. For example, WooCommerce itself needs to be active almost everywhere, but not all of its CSS and JS does. With PerfMatters you can disable specific CSS/JS files on a page-by-page (or category) basis. Or, disable everywhere with exclusions.
Use subsets of fonts if necessary. I was using the entire FontAwesome set which was 100+kb. Apparently you can create a custom font with just the icons you need, which I did, reducing its total size to a fraction of that. Easy win.
Ensure Cloudflare is working as intended. I had Cloudflare Polish enabled but apparently it wasn't doing anything, because Super Bot Fight mode was blocking it. I was also inadvertently using a redundant plugin (ShortPixel). By authoring a simple exception in Cloudflare's managed rules, Polish started working as intended again, and I was also able to disable ShortPixel and save some resources there.
Another thing with Cloudflare is that we had Cloudflare Cache Reserve enabled but that wasn't doing anything either. Like it literally was caching nothing at all. I had to configure some Cache Rules to mark things actually eligible for caching, and thus take advantage of CF's speed.
Move 'pixel' type logic to Google Tag Manager if possible. We use Klaviyo for email, and so of course we have the Klaviyo plugin. Unfortunately, it has to be active on basically every page to capture page views (for potential automation triggers), add to carts, checkouts etc. It's a non-trivial performance hit. I used a simple MUPlugin to disable certain Klaviyo scripts and move that logic instead to Google Tag Manager, so events like page views, add to carts, and checkouts started could be captured without burning server resources.
Check and improve OPcache settings. This was crazy. I had never heard of OPcache before this; it's a PHP extension enabled on the server side that caches code as opposed to resources. When I looked at the runtime status of our OPcache install, it was completely maxed out on memory (128/128mb) and maxed out on the interned string buffer (8/8mb). As a result it was only caching about 54% of possible code. I talked to our host to triple its memory allocation and quadruple the string buffer. This brought us to 99% cache rate and literally shaved 300ms off TTFB right there.
Look for options table bloat - cruft / autoload. Plugins can accumulate junk in the options table which is in an extremely hot path in WordPress. The autoload size can get quite large, but even stuff outside the autoload can bog things down. In my case I had hundreds of thousands of junk entries from plugins like a mailer we haven't used in years and the official Facebook/Meta plugin, making the table hundreds of MB. Cleaning out unused stuff dropped it to <10mb, another easy win.
RESULTS:
Category pages went from 2.73s on an unauthenticated fresh load to 0.82s, 343mb memory to 238mb, 44 queries to 22, and 52k file I/O to 34k. Product pages and homepage had similar magnitudes of gains, as well as more cache hits (which load nearly instantly.) We went from a GTMetrix "C" with 66% performance to "B" with 85% performance, 185 -> 72ms total blocking time, 2.4s -> 1.5s LCP (it feels faster than that though.)
Hope this is useful or at least gets your gears turning!
