DEV Community: Andy Kirchbühler

Beyond WooCommerce.com’s Selective Plugin Loading

Andy Kirchbühler — Sat, 01 Aug 2026 18:06:05 +0000

Why the final plugin filter is only half of the architecture

https://developer.woocommerce.com/2026/07/21/selective-plugin-loading/

WooCommerce Engineering recently published a useful account of how WooCommerce.com reduces WordPress bootstrap cost by loading fewer plugins on selected requests.

The article deserves attention for a simple reason: it names and measures a problem that WordPress performance discussions often overlook.

A WordPress installation has one global list of active plugins.

A single request rarely needs all of them.

WooCommerce.com found that unrelated plugins could consume 10 to 20 percent of the generation time of an uncached blog request. On selected internal endpoints, loading only the required plugins reduced memory use by more than 50 percent. Reported request times dropped from around 800 ms to 475 ms and from 880 ms to 550 ms. An early test on product pages produced roughly a 10 percent improvement in page-generation time.

That is valuable evidence.

It confirms that plugin bootstrap is not merely theoretical overhead. Every loaded plugin may register hooks, instantiate services, read options, load translations, attach REST routes or initialize integrations that the current request never uses. Full-page caching reduces how often this work occurs, but it cannot remove the cost from cache misses, logged-in sessions, APIs and other dynamic requests.

WooCommerce.com solves this with route-specific rules in an early MU-plugin. The MU-plugin filters WordPress’s active plugin list before regular plugin files are included.

The result is real: excluded plugins do not execute.

But the filter itself is only the final switch.

The more interesting question is what had to happen before that switch could be operated.

Selective plugin loading is not one architecture

Several public WordPress plugins already provide selective plugin loading.

Plugin Organizer can selectively disable plugins by managed URL or post type and installs an MU component for its early loading mechanism.

Freesoul Deactivate Plugins supports pages, posts, custom post types, archives, backend pages, devices and custom URLs. Its documentation explicitly states that disabled plugins do not merely lose their assets. Their PHP code does not run for the affected request.

Plugin Load Filter also installs an MU-plugin component and distinguishes between administrative requests, page types, post types, devices and other WordPress contexts.

These are genuine PHP execution-control tools.

They should not be confused with asset managers that merely suppress CSS or JavaScript after the responsible plugin has already loaded.

But the fact that several solutions eventually influence the same WordPress plugin list does not make their architectures equivalent.

An MU-plugin may be:

the complete selection engine
a runtime rule interpreter
a URL and post-type matcher
or merely the handoff through which WordPress receives a decision prepared elsewhere

Looking only at the final filter point is like comparing two buildings because both have a light switch.

The wiring still matters.

The hidden cost of deciding what not to load

A WordPress-internal selector can prevent expensive regular plugins from loading. That can easily produce a net performance gain.

WooCommerce.com has demonstrated exactly that.

But the selection itself is not free.

Before an MU-plugin can execute inside wp-settings.php, a relevant part of the WordPress bootstrap already exists. Configuration has been loaded. Database and object-cache infrastructure have been initialized. Core files and the MU-plugin environment are available. The selector may then read its settings, inspect the request, evaluate route rules and modify the active plugin list.

This does not necessarily mean there is one dedicated SQL query for active_plugins on every request. The option may be part of WordPress’s autoloaded options or served through an object-cache layer.

That distinction is technically important, but it does not remove the architectural cost.

The WordPress options, database and cache infrastructure must already exist before a WordPress-internal selector can use them. A persistent object cache also requires additional infrastructure. It is not a magical property of every ordinary WordPress installation.

The useful question is therefore not:

Does selective plugin loading save time?

It often does.

The more revealing question is:

How much application runtime must exist merely to decide how much application runtime should exist?

A selector can be worthwhile while still paying an avoidable WordPress-internal decision cost.

Those two statements do not contradict each other.

WooCommerce.com chose a pragmatic internal solution

The WooCommerce.com implementation is designed for a large, engineering-owned platform.

Its rules live in code, pass through review and deployment processes, and are monitored like other performance-sensitive changes. The team deliberately focuses on predictable, high-traffic routes where the expected plugin requirements can be understood and tested.

The difficult part is not filtering the array.

The difficult part is determining what a route actually needs.

WooCommerce Engineering describes dependency discovery as the hard part. Developers inspect route code, follow dependencies, manually exercise request flows, add tests, deploy incrementally and monitor errors and performance data. Stateful or broad requests such as checkout, cart, account, admin, cron, webhooks and payment callbacks require extra caution.

That makes the solution appropriate for WooCommerce.com.

It does not automatically make it a generally reusable context engine for arbitrary WordPress installations.

This is not criticism of the implementation. It is simply the boundary of the selected architecture.

WooCommerce.com uses a WordPress-controlled environment to decide how much of that environment should load.

That can work very well when routes are narrow, rules are owned by engineers and failures can be monitored and rolled back.

The enforcement point and the decision process are different things

Selective plugin loading contains at least two separate tasks:

Determine the execution scope required by the request.
Prevent WordPress from loading plugins outside that scope.

WordPress offers an early point at which the plugin list can be changed.

That is the enforcement mechanism.

It does not tell us how the decision was produced.

A simple implementation may inspect REQUEST_URI and compare it with a list of exact paths, prefixes or patterns. A more advanced WordPress plugin may use page IDs, post types, device classes, backend screens or user-related conditions.

These approaches can be useful. They can also become increasingly dependent on runtime expressions, duplicated routing knowledge and manually maintained exceptions.

There is another possible abstraction:

Request signals
    ↓
Execution context
    ↓
Runtime bucket
    ↓
Prepared plugin scope
    ↓
WordPress loads only that scope

The distinction is subtle but important.

A URL rule asks:

Which rule matches this URL?

A runtime bucket asks:

What kind of application runtime does this request require?

Several URLs, entry points or request variants may belong to the same runtime bucket. Conversely, requests that appear similar at URL level may require different execution scopes.

The quality of selective loading therefore depends not only on how early plugins are filtered, but also on the resolution and reliability of the context model behind the filter.

Post types are useful, but they are not the complete request universe

WordPress-oriented selectors often begin with understandable concepts:

pages
posts
custom post types
archives
frontend versus backend
desktop versus mobile.

These are useful dimensions. They are also only part of the request landscape.

A modern WordPress installation may also process:

REST requests
AJAX actions
cron requests
login and account flows
administrative screens
webhooks
payment callbacks
feeds
internal tools
crawler requests
cache-related operations
application-specific endpoints. Treating the whole WordPress backend as one indivisible runtime is safe, but often unnecessarily broad.

Likewise, treating every custom URL as an expression that must be interpreted during the request can create its own maintenance and execution overhead.

A more differentiated execution model can map requests into prepared runtime contexts instead of constructing a growing condition language around individual URLs.

This does not make URL-based selection obsolete.

A URL can be an excellent signal.

The question is whether the URL is evaluated as an isolated runtime rule, or used as one input into an already prepared execution context.

The MU-plugin does not equalize the solutions

This point is easy to miss.

If two systems both contain an MU-plugin, it is tempting to classify them as variations of the same technique.

That conclusion is too quick.

In one system, the MU-plugin may perform nearly everything:

WordPress starts
    ↓
MU-plugin loads
    ↓
settings are retrieved
    ↓
URL and context rules are evaluated
    ↓
active plugin list is filtered

In another system, the MU component may have a much narrower role:

request context and execution scope are prepared
    ↓
WordPress reaches the early handoff
    ↓
MU component applies the prepared scope
    ↓
regular plugins load

The MU component in the second model is not the context engine.

It is the bridge into WordPress.

The shared enforcement point does not erase the difference between the decision paths that reached it.

Where WP-Rush fits

For transparency: I am the developer of WP-Rush.

WP-Rush was created because I did not want WordPress to perform most of the work required to decide how much WordPress should run.

It uses a staged, request-aware execution model. The required execution scope is completed before regular plugins are loaded. WordPress then continues normally inside that selected scope.

The public architectural contract is deliberately clearer than the internal implementation details:

request processing begins before the regular plugin-loading phase
the MU component is an early WordPress handoff, not the complete selection engine
the execution scope is prepared before regular plugins initialize
plugins outside that scope do not execute for the request
uncertain or sensitive contexts can retain a broader or complete runtime.

WP-Rush organizes requests through runtime buckets rather than relying only on WordPress post types or individual page rules.

A bucket represents an execution context.

Different public requests may share one bucket. Administrative requests can be separated into more specific runtime classes instead of treating the entire backend as one block. Asynchronous and other non-document requests can receive their own scopes.

WP-Rush also provides a URL-oriented mode, but the URL mode does not require users to build a runtime expression language. URLs can be associated with prepared execution contexts rather than repeatedly interpreted through chains of conditions during every request.

The point is not that URL selection is bad.

The point is that URL selection does not have to mean runtime expression processing inside WordPress.

The internal preparation, classification and safety mechanisms remain product implementation details. Publishing every internal step would turn an architectural explanation into a reconstruction guide.

A reader can still evaluate the public system boundary:

When does context processing begin?

When is the scope complete?

What code is prevented from executing?

What happens when the context is uncertain?

Those are legitimate architectural questions even when the proprietary implementation is not published line by line.

WP-Rush describes itself as a request-aware execution layer that reduces the plugin runtime created for a request before normal plugin execution begins.

What about server-level classification?

Some infrastructure-owned systems move request classification even further toward the web server, reverse proxy or hosting layer.

That is a legitimate architecture class.

It may also require privileged access to Nginx, PHP pool settings or custom hosting infrastructure that ordinary WordPress installations do not provide. The discussion below the WooCommerce Engineering article itself notes that rules can exist outside the MU-plugin path, but that such approaches require deeper server access and infrastructure control.

Earlier is not automatically better.

A very early classifier with poor context may be less useful than a slightly later classifier with reliable information.

The relevant comparison remains:

selection cost
context quality
scope granularity
maintenance effort
deployment requirements
and safe fallback behaviour

Without enough public technical detail, naming individual proprietary infrastructure systems would turn this article into speculation. The architectural class is worth acknowledging even when particular products cannot yet be compared fairly.

Five questions worth asking any selective-loading solution

When two tools both claim to “load only the plugins that are needed,” ask more than whether they filter active_plugins.

Ask:

1. How much WordPress runs before the decision exists?

Does the selector require WordPress’s database, options, object cache and its own plugin runtime before it can classify the request?

2. Where does the context model come from?

Is the decision based on runtime URL expressions, WordPress post types, hard-coded route rules, prepared contexts or another classification layer?

3. How granular is the execution model?

Can it distinguish only pages and post types, or also administrative, asynchronous, API and other request classes?

4. What happens when the request is ambiguous?

Does the system guess aggressively, fail closed, or fall back to a broader safe runtime?

5. Is the MU component the engine or merely the handoff?

The answer can reveal more about the architecture than the presence of the MU-plugin itself.

Same goal, different selection cost

WooCommerce.com has done WordPress performance work a favour.

Its Engineering article confirms three important facts:

Global plugin loading can create substantial request overhead.
Preventing unnecessary plugin execution can produce measurable improvements.
Safely determining the required plugin scope is harder than filtering the plugin list.

WooCommerce.com solves that problem with route-owned rules inside a controlled engineering environment.

Plugin Organizer, Freesoul Deactivate Plugins and Plugin Load Filter provide generally available WordPress interfaces for related forms of selective plugin loading.

Infrastructure-level systems may move parts of classification toward the server.

WP-Rush uses a request-aware context and bucket model in which its MU component is primarily the early handoff into WordPress, not the whole decision engine.

These approaches share a goal.

They do not share the same selection cost, context model, granularity or operational architecture.

Selective plugin loading should therefore not be compared only by asking:

Can it remove a plugin from the final list?

The better question is:

How much had to run, and how much had to be known, before that list could be produced?

The final filter point is only half of the architecture.

Sources:

Why WordPress Optimization Often Starts Too Late

Andy Kirchbühler — Thu, 12 Mar 2026 12:11:31 +0000

Most WordPress optimization starts after the system has already done too much work.

That is the blind spot.

We optimize images, defer scripts, enable caching, clean databases, remove CSS, reduce plugin count, and chase better Lighthouse scores - all useful things. But very often, we do all of that without asking a more basic question first:

Why is WordPress doing this much work for this request at all?

That question matters because many WordPress performance problems do not begin at the output layer. They begin earlier, at the execution layer.

And if the system is already doing unnecessary work before the response is even ready, then a lot of optimization advice starts too late.

The usual optimization path

When a WordPress site feels slow, the response pattern is familiar:

enable page caching
optimize images
defer JavaScript
minify CSS
remove unused plugins
add a CDN
improve Core Web Vitals

None of that is wrong.

The problem is not that these steps are useless. The problem is that they usually focus on making an existing workload cheaper, not on questioning whether that workload should exist in the first place.

That is a big difference.

Because a system can be "optimized" and still be structurally wasteful.

WordPress often executes broadly, not selectively

This is where WordPress becomes interesting.

A typical request in WordPress does not begin with strong selectivity. It often begins with broad availability. Themes, plugins, hooks, builders, commerce logic, helper layers, integrations, marketing additions, and general-purpose code can all become part of the request path before the system has seriously justified why this specific URL needs them.

That is the architectural blind spot.

The system behaves as if every request deserves access to most of the machinery, and only later do we try to reduce the cost of that decision.

In other words:

WordPress performance is often treated as an optimization problem when it is partly an execution scope problem.

A simple example

Imagine a site that uses WooCommerce, a page builder, analytics plugins, form plugins, search helpers, and several utility plugins.

Now imagine a request for a very simple informational page.

From a human point of view, that page may only need a fraction of the site's total functionality. But from WordPress's point of view, the request may still pass through a large amount of generalized code because the system is designed around broad plugin availability and shared hooks.

So what happens?

The request becomes expensive before frontend optimization even begins.

At that point, image optimization, asset minification, and caching may still help - but they are helping after the system has already accepted too much execution as normal.

That is why some optimization wins feel real but incomplete. The page gets lighter, but the request model remains permissive.

Output optimization is not the same as execution reduction

This distinction is easy to miss.

A lot of WordPress performance work is really output optimization:

smaller files
fewer requests
delayed scripts
cached responses
compressed assets
better delivery

Again, all useful.

But none of this necessarily reduces how much WordPress had to execute to produce the response in the first place.

That is a different category of problem.

You can improve delivery without improving selectivity.
You can improve rendering without improving execution scope.
You can improve scores without questioning workload generation.

And that is often where WordPress performance advice becomes misleading.

It creates the impression that performance is mainly about polishing output, when in many cases a large part of the problem begins earlier: the system is simply doing too much for the request.

Why caching does not solve the underlying issue

Caching is probably the most important example here.

Page caching is useful because it avoids repeating the same expensive work on every request. That is valuable. On busy sites, it can make a dramatic difference.

But caching does not answer the deeper architectural question. It does not ask whether the uncached request path is justified. It only makes repeated use of that path less costly.

So caching should be understood for what it is:

a powerful amortization layer, not a cure for excessive execution scope.

That is why a site can appear "fast enough" under cache while still having an unnecessarily heavy uncached request model underneath. And that matters whenever cache is bypassed, missed, invalidated, varied, or simply unavailable in certain contexts.

The earlier performance question

Before tuning output, it is worth asking a more structural set of questions:

Why is this code running on this request?
Why is this plugin active in this context?
Why is this subsystem loaded here?
Why is this query executed for this URL?
Why does this request get the full machinery?

Those are not classic optimization questions. They are architecture and execution questions.

And they often lead to a different kind of performance thinking:

not just "How do we make this faster?"
but also
"How do we stop irrelevant work from happening here at all?"

That shift matters.

Because once you start thinking in terms of workload prevention instead of workload polishing, the whole diagnosis changes.

What this changes in practice

This does not mean developers should stop optimizing assets, caching, or frontend behavior.

It means those things should not be the only lens.

A more complete approach to WordPress performance starts by separating two concerns:

1. How much work is WordPress doing for this request?
2. How efficiently is the result delivered once that work is done?

Most optimization discussions begin with question 2.

But in many cases, question 1 deserves to come first.

That changes how you inspect a slow site. Instead of only asking which assets are too large or which scores are too low, you also ask whether the request path itself is overloaded by unnecessary global behavior.

That is a very different mindset.

And in WordPress, it is often the more important one.

A better mental model

A useful way to think about this is:

Optimization improves the cost of work
Prevention improves the necessity of work

Both matter.

But necessity comes first.

Because if the system is generating avoidable work, then improving the cost of that work is only part of the answer. The cleaner answer is to reduce or prevent the irrelevant execution before it spreads through the request.

Conclusion

Most WordPress optimization starts too late because it begins after the system has already accepted too much execution as normal.

That is the architectural blind spot.

The usual tools - caching, minification, image optimization, CDN delivery, script deferral - are still useful. But they often work downstream of the more important question:

Why is WordPress doing this much work for this request at all?

That is the question more developers should ask earlier.

Because better performance is not only about delivering the result more efficiently.

It is also about preventing unnecessary execution before it becomes a result that needs optimization in the first place.

That is why "WordPress optimization" is sometimes too narrow a phrase.

In many cases, the real issue is not just optimization. It is workload governance.

Learn more about the consequences of starting Page Optimization too late and how to solve this serious problem: https://www.wp-rush.com "WP-Rush - WordPress Performance by Prevention"

WordPress Optimization Has an Architectural Blind Spot

Andy Kirchbühler — Thu, 26 Feb 2026 09:44:35 +0000

Most WordPress performance discussions focus on compression, caching, asset minification, and render timing. These techniques are effective — but they operate at the end of the request lifecycle.

There’s a structural layer that often goes unexamined. And it sits at the very beginning of every request.

The Boot Sequence Nobody Talks About

Before a single template is rendered, before output buffering begins, WordPress performs a full bootstrap:

Core loads
All active plugins are included
Hooks are registered
Classes are instantiated
Conditional logic is wired

This happens before WordPress fully resolves what the request actually needs. In other words: execution scope is determined globally, not contextually.

Context-Blind Initialization

During plugins_loaded, WordPress iterates over every active plugin.

That includes:

eCommerce logic on non-commerce pages
Membership frameworks on public landing pages
Slider libraries on pages without sliders

Even if those plugins later decide not to output anything, their initialization cost has already been paid.

This is not a bug. It’s an architectural characteristic.

Output Optimization vs Execution Scope

Most optimization plugins intervene late:

Minifying assets
Deferring scripts
Manipulating output buffers
Rewriting HTML

These improve delivery efficiency. But they do not reduce execution scope.

There’s a distinction between:

Reducing the size or timing of the response
Reducing the amount of code that runs to generate that response

Both affect perceived performance. Only one affects server workload at its root.

Caching Is Not the Same Thing

Page caching improves performance dramatically. But it amortizes work — it does not eliminate the underlying execution path.

At some point, the full stack executed. If uncached requests are significantly slower, that gap reveals the actual execution cost.

Caching reduces frequency of work. It does not redefine necessary work.

The Architectural Question

What if performance discussions separated these layers explicitly?

Delivery optimization
Execution scope control
Work avoidance

Instead of treating all three as variations of the same concept. If a system loads everything for every request, optimization will always be reactive. If execution scope is context-aware early in the request lifecycle, optimization becomes preventive.

That’s not ideology. It’s a difference in intervention timing.

A Shift in Framing

Instead of asking:

“How do we optimize what runs?”

We might ask:

“Why does it run in the first place?”

That single question changes the entire performance conversation. And it’s surprisingly absent from most WordPress optimization debates.

WordPress Performance by Prevention: https://www.wp-rush.com/