WP-Rush: Load the Runtime the Request Needs — Not the Runtime the Site Owns

A WordPress site may need dozens of active plugins as a complete application.

A single request usually does not.

That difference matters because WordPress starts each request from one global list of active plugins. A blog article, a product page, an API endpoint, an administrative request and a checkout may require completely different functionality — yet they normally begin by loading the same plugin runtime.

WP-Rush exists to change that starting condition.

WP-Rush is a request-aware execution layer that determines the required plugin execution scope before regular WordPress plugins are loaded.

It does not merely optimize the output produced by WordPress. It prevents plugin runtime that the current request does not need from being created in the first place.

In July 2026, WooCommerce Engineering published an unusually clear account of selective plugin loading on WooCommerce.com.

Its central observation was simple:

The active plugin list is global, while the needs of an individual request are local.

WooCommerce.com found that unrelated plugins could account for 10–20% of the generation time of an uncached blog request. On selected internal routes, loading fewer plugins reduced PHP memory usage by more than 50%. Individual endpoints dropped from approximately 800 milliseconds to 475 milliseconds and from 880 milliseconds to 550 milliseconds. An early implementation on product pages improved page-generation time by about 10%. The WooCommerce Developer Blog

This confirms something conventional WordPress performance work frequently overlooks:

Plugin bootstrap is not a theoretical cost.

Every loaded plugin can define classes, instantiate services, read options, register hooks, attach REST routes, initialize integrations and prepare work that the current request may never use.v

Page caching can prevent PHP from running on a cache hit. It does not remove this cost from cache misses, logged-in requests, APIs, asynchronous operations or other dynamic requests. The WooCommerce Developer Blog

WooCommerce.com has therefore provided an authoritative diagnosis:

Loading the complete active plugin runtime for every request can be a measurable performance problem.

How WooCommerce.com speeds up requests by loading fewer plugins

WooCommerce.com uses a pragmatic internal solution.

An early MU-plugin filters WordPress’s active_plugins option before regular plugins are included. Route-specific PHP rules match request URIs against exact paths, prefixes or regular expressions and remove plugins known to be unnecessary for those routes.

The approach is intentionally conservative:

• rules are maintained in code;
• exclusions are preferred over fragile minimal allowlists;
• dependency assumptions are reviewed and tested;
• broad or stateful requests receive additional caution;
• changes are monitored and can be reverted independently.

This is a sensible implementation for a large platform with engineering-controlled routes, continuous integration, production monitoring and the ability to maintain application-specific rules. WooCommerce explicitly presents it in that context.

How WooCommerce.com speeds up requests by loading fewer plugins

It also exposes the real difficulty.

The WordPress filter is not the hard part.

The hard part is determining, early and reliably, which execution scope a request actually requires.

Discussions about selective plugin loading often treat the following as one operation:

1. Determine which plugins the request needs.
2. Prevent WordPress from loading the others.

They are not the same problem.

WordPress provides an early point at which the active plugin list can be changed. That is the enforcement point.

But the quality and safety of the result depend on how the required execution scope was determined before that list was changed. That is the context and decision layer.

A route-specific MU-plugin may infer intent from:

• the request URI;
• path prefixes;
• regular expressions;
• query parameters;
• cookies;
• a manually maintained route map.

This can work extremely well for narrow and predictable endpoints.

It becomes harder when requests are dynamic, stateful or affected by implicit dependencies. WooCommerce.com consequently excludes or treats with particular caution broad request types such as checkout, cart, account, cron, webhooks, payment callbacks and several query-parameter entry points. Its engineers describe dependency discovery, testing and continued monitoring as the difficult part of the system.

How WooCommerce.com speeds up requests by loading fewer plugins

That is not a failure of the WooCommerce implementation.

It is the architectural boundary of solving context selection primarily through application-specific route rules inside a WordPress-controlled system.

Two systems may ultimately influence the same WordPress plugin-loading list and still represent fundamentally different architectures.

The decisive questions are:

• When does context processing begin?
• What information is available to the decision process?
• Is the required execution scope prepared before regular plugins load?
• Does the system merely match isolated routes, or does it provide a dedicated context model?
• What happens when a request cannot be classified safely?

The final WordPress mechanism only applies the result.

It does not explain how that result was produced.

This distinction matters because WP-Rush is sometimes compared with Plugin Organizer, Freesoul Deactivate Plugins, Plugin Load Filter or custom option_active_plugins snippets merely because all of them can prevent selected plugin files from being included.

That comparison observes the final switch but ignores the control system connected to it.

WP-Rush was not designed as another settings interface around route-specific plugin exclusions.

It is a dedicated request-aware context and execution layer.

Its context process begins before the regular WordPress plugin-loading phase. It completes the required plugin execution scope before regular plugins are loaded and before their normal initialization, hook registration and runtime work can begin.

WP-Rush does not wait for the complete regular plugin runtime to determine how much of that runtime the request should receive.

The simplified execution model is:

Incoming request
↓
early request-aware context processing
↓
runtime context and execution scope
↓
required plugin set
↓
normal WordPress execution within that scope


The exact internal classification, preparation and safety mechanisms are part of the product implementation and are not published as a reconstruction guide.

The public architectural contract is clear:

• context processing begins before the regular plugin runtime;
• the execution scope is completed before regular plugins are loaded;
• plugins outside that scope are not initialized for the request;
• uncertain or sensitive contexts can retain a broader or complete runtime;
• WordPress then operates normally inside the selected scope.

The existing WP-Rush documentation already describes this principle as early context recognition followed by runtime-bucket and plugin-set selection.

WP-Rush: Why Request-Aware WordPress Execution Exists

Asset optimization tools can prevent selected CSS or JavaScript files from appearing in the generated page.

That can improve browser performance, but it does not necessarily prevent the plugin’s PHP code from being included and initialized.

By the time an asset manager decides not to print a stylesheet, the responsible plugin may already have:

• loaded PHP files;
• created objects;
• read options;
• registered hooks;
• initialized integrations;
• performed database work;
• allocated memory.

WP-Rush works on the server-side execution scope that exists before those downstream effects.

Asset optimization and execution prevention can complement one another. They solve different problems.

Aggressive reduction without reliable context would be reckless.

WP-Rush does not assume that every request should receive the smallest imaginable plugin set. A technically minimal runtime is useless if it breaks the application.

The objective is:

Do not create runtime that is reliably known to be unnecessary.

Where context is ambiguous, sensitive or insufficiently reliable, WP-Rush can preserve a broader or complete runtime. This conservative fallback is part of the architecture, not an admission of failure. The current WP-Rush documentation already makes context confidence and broader fallbacks explicit.

Performance by Prevention must remain subordinate to correctness.

WooCommerce.com focuses on large, engineering-owned applications because that is the environment in which its internal implementation operates.

But high traffic does not create unnecessary plugin execution.

High traffic multiplies it.

The underlying cost can exist on any plugin-heavy WordPress installation whenever an uncached or dynamic request initializes code it does not need. A normal site with 30 or 40 active plugins may execute the same unnecessary bootstrap work per request even without enterprise traffic.

The relevant question is therefore not only:

How many visitors does the site receive?

It is also:

How much unnecessary runtime does each PHP request create?

WP-Rush does not replace:

• page caching;
• object caching;
• database optimization;
• CDN delivery;
• image optimization;
• asset optimization;
• efficient themes and plugins.

Those measures improve necessary work or reduce how frequently WordPress must perform it.

WP-Rush addresses the earlier question:

Was all of this work necessary for the current request in the first place?

A warm page cache

Caching improves reuse.

WP-Rush reduces the execution scope that must exist when reuse is not possible.

The WooCommerce Engineering article is important because it removes uncertainty about the underlying problem.

Loading fewer plugins can substantially reduce memory use and latency. The global plugin runtime is often larger than the local request requires. Preventing unnecessary bootstrap work is a real performance lever.

How WooCommerce.com speeds up requests by loading fewer plugins

WooCommerce.com implements that principle through internal, route-specific rules maintained by its engineering organization.

WP-Rush begins from the same fundamental observation but treats context determination and execution-scope control as a dedicated product architecture.

The goal is not to make WordPress process unnecessary work faster.

The goal is to prevent WordPress from creating that unnecessary plugin runtime at all.

That is Performance by Prevention.

That is WP-Rush.