WP-Rush: Why Request-Aware WordPress Execution Exists


WP-Rush is not a cache, CDN, database optimizer or asset optimizer. It addresses an earlier problem: WordPress can load a globally active runtime even when the current request requires only part of it.

Why WP-Rush Exists

A WordPress site may contain many active plugins because the site, as a whole, needs their functionality.

A specific request does not necessarily need all of those functions.

Without an early request-aware decision layer, WordPress may still initialize plugin code, hooks, integrations and related runtime paths that are irrelevant to the current request.

WP-Rush exists because WordPress knows which plugins are active, but does not natively decide which active plugins are necessary for the current request.

The Missing Optimization Layer

Most performance measures improve work after it already exists:
  • - caching improves delivery
  • - CDNs improve distribution
  • - compression reduces transfer size
  • - object caches reduce repeated data work
  • - database tuning improves query execution

These measures can be valuable, but they do not necessarily prevent unneeded plugin runtime from being created in the first place.

WP-Rush operates before delivery optimization. Its role is execution optimization through prevention.


What WP-Rush Solves

WP-Rush addresses unnecessary WordPress and plugin execution when a request can be assigned to a sufficiently reliable context.

Examples may include public page requests, specific functional areas, administrative contexts, asynchronous requests or other request types with different runtime requirements.

The goal is not to make every request minimal.
The goal is to avoid loading runtime that is not required for that request.


Why This Is Technically Possible

A request reaches WordPress before the normal plugin runtime has fully started.

If the request can be classified early enough, a runtime decision can be made before the usual global plugin initialization proceeds.

WP-Rush uses this early decision point to select an appropriate runtime for the request context.

Incoming request
  • → early context recognition
  • → runtime bucket selection
  • → required plugin set
  • → normal WordPress execution within that selected runtime

Conservative Design / Why It Is Not “Plugin Disabling”

WP-Rush does not assume that every request can be safely reduced.

Where the request context is uncertain, ambiguous or sensitive, WP-Rush can retain a broader or complete runtime.

The system is designed around context confidence: reduction is used where the request can be reliably classified, not where classification would introduce avoidable risk.


What WP-Rush Does Not Solve

WP-Rush does not replace page caching. WP-Rush does not make required plugin code faster by itself.
WP-Rush does not fix slow external APIs, inefficient themes, bad database queries or broken plugin logic.

Its benefit exists where WordPress would otherwise execute runtime that the current request does not need.


Conclusion

WP-Rush is a request-aware execution layer for WordPress.

It complements delivery optimization by preventing unnecessary plugin runtime before that runtime is created.