Selective Plugin Loading Cuts WooCommerce.com Memory 50%

Every performance rescue I have been called into for the last ten years follows the same shape. Something is slow, something is fatal on Tuesdays, or something is eating memory on the API host nobody was billing for. And every time I pull the trace, the same silent culprit is there: WordPress loaded every single active plugin on every single request, whether the request needed them or not.

That is not a bug. That is how WordPress works. On a small site it does not matter. On a store with fifty active plugins and a REST endpoint that a mobile app hits every three seconds, it matters a lot. Which is why yesterday’s WooCommerce engineering post on how the WooCommerce.com marketing site loads fewer plugins per request is not internal trivia. It is a pattern worth studying, and — carefully — worth borrowing.

I want to walk through what they actually shipped, why the pattern is safe on some routes and terrifying on others, and how I would think about it on a real client store next week.

What is actually new

On July 21, 2026, Thilina Pituwala published How WooCommerce.com speeds up requests by loading fewer plugins on the WooCommerce Developer Blog. It is an engineering post from the team that runs the marketing and documentation site behind woocommerce.com, and it documents a pattern their platform team has been running in production.

The mechanism is small. A must-use plugin — the kind PHP loads before regular plugins — hooks the option_active_plugins filter and, for a controlled set of routes, returns the active plugin list minus everything the current route does not need. The exact shape from the post:

add_filter( 'option_active_plugins', function ( array $plugins ): array {
    if ( ! should_limit_plugins_for_this_request() ) {
        return $plugins;
    }
    return array_values( array_diff( $plugins, plugins_to_skip_for_this_request() ) );
} );

That is it. WordPress calls get_option( 'active_plugins' ) early in the boot sequence to decide which plugin files to include, the mu-plugin quietly hands back a shorter list, and half the plugin graph never enters the request.

The numbers the post cites, measured against production WooCommerce.com traffic: on targeted requests, memory use drops by more than 50%. The subscription-lookup endpoint goes from around 800ms to 475ms. The plugin-updates endpoint goes from around 880ms to 550ms. Product pages get a roughly 10% generation-time improvement. Those are not synthetic numbers on a Hello World install.

The post is honest about what they refused to touch. wc-ajax requests, wc-api webhooks, REST calls with query parameters, and file downloads are all on the “do not trim” list. Checkout, cart, account flows, cron, webhooks, and payment callbacks are called out as high-caution areas where a missing plugin can silently cost money. Route matching is done via explicit paths, prefixes, and regexes, with the rules reviewed like production code, and both allowlist and exclusion strategies are on the table.

The quote worth pinning to a wall: “A missing plugin might only fail on one product, one locale, one request parameter, one cache miss, or one logged-in state.”

Why it matters for WordPress / WooCommerce people

Two reasons.

First, this is WooCommerce’s own platform team publicly saying that on any WordPress application of a certain size, the every-plugin-every-request model is a real bottleneck. That has been true for a decade, but it mostly lived in whispered agency lore and a handful of managed hosts’ internal tooling. Having it on the official developer blog, with numbers and code, makes it a first-class conversation instead of a hack.

Second, the pattern rhymes with the direction WooCommerce is already going. Product object caching becomes default-on for new stores in WooCommerce 11.0 on July 28. Store API endpoints are being deduplicated. Persistent object caches are moving from “expert setting” to “boring baseline.” Selective plugin loading is the next layer up: after you have cached the data, do not even load the code that would have queried it.

On the risk side, this is also the pattern that has bitten more than one agency I know. Someone drops a route-based skip list into mu-plugins/, everything looks great in staging, and three weeks later a wc-ajax add-to-cart on a specific product variation from a specific browser locale silently fails because the multilingual plugin was excluded from that path. The failure mode is exactly what Pituwala describes: narrow, hard to reproduce, invisible in logs unless you are watching for it.

What I would do (or not do) about it

I would read the post twice, once for the pattern and once for the caveats. Then, on a large client store where memory or latency is actually a problem I can measure — not a theoretical one — I would sketch a two-week experiment.

Week one: instrument. Add plugin-load and memory logging on the routes that are hot. Pick two or three narrow, boring endpoints that clearly do not need payments, do not touch cart or checkout, and have no third-party integrations attached. Read-only product feeds, a public REST endpoint that returns store hours, a marketing landing page hit by a CDN. Prove the numbers on the current stack first, because you cannot claim a 50% memory reduction later if you never measured the 100%.

Week two: skip. Ship a small mu-plugin with a single route rule and a very short exclusion list. Test both cold cache and warm cache, both logged-in and logged-out, with a full regression pass on anything the excluded plugins might have quietly hooked into. Watch production for fatals, watch memory, watch response times, and keep a kill switch that flips the filter back to a no-op with a config change, not a deploy.

What I would not do: ship this pattern to a store where the payment gateway, the tax plugin, or the shipping calculator is even indirectly in scope. Do not exclude anything from wc-ajax, ever. Do not run it under a managed host that already does its own route-based plugin unloading, because you will fight the platform. Do not treat this as a substitute for actually deleting the twelve plugins nobody uses — the first performance win on almost every WooCommerce store is still the one where you audit the plugin list and remove what is not earning its rent.

And please do not do this on a WordPress 7.1 Beta 2 staging site this week. One moving target at a time.

The good news is the pattern is small, the code is public, and the failure modes are well understood by the team that put it in production. That combination is rarer than it should be.