Selective Plugin Loading Is an Outcome, Not an Architecture
Reducing the number of WordPress plugins executed for a request can significantly reduce PHP work, memory consumption and application bootstrap overhead. The basic idea is simple: A WordPress site may have dozens of active plugins, while an individual request usually needs only a subset of them. Preventing unnecessary plugins from executing is therefore a legitimate form of WordPress performance optimization. But there is an important distinction that is often lost when different solutions are grouped under the term selective plugin loading:
Selective plugin loading describes an outcome. It does not describe the architecture that produced that outcome.
Two systems can ultimately cause WordPress to load the same reduced list of plugins while using fundamentally different decision models, execution paths and runtime costs. That distinction matters.
The Final Plugin List Is Only the Enforcement Point
WordPress normally works with a site-wide set of active plugins. Before regular plugin files are included, the set of plugin entry files that WordPress will load can be influenced so that only a subset is included for a particular request. If a plugin's entry file is not included, its normal plugin bootstrap code does not execute for that request. That is real execution control. It is fundamentally different from asset optimization that merely prevents a plugin's CSS or JavaScript from reaching the browser after the plugin itself has already run. But changing the final plugin list answers only one question:
Which plugins will WordPress load?
It does not answer another, equally important question:
How was that decision produced?
This separates selective plugin loading into two different problems:
Decision: Determine what execution scope the current request requires.
Enforcement: Prevent plugins outside that scope from executing.
The enforcement mechanism can be similar across different systems. The decision architecture does not have to be.
The Cost of Deciding What Not to Load
A selector can save substantial execution time by preventing unnecessary plugins from running. But the selector itself also has an execution cost. A WordPress-internal selection process may look conceptually like this:
Request
↓
WordPress bootstrap begins
↓
Parts of the WordPress runtime are initialized
↓
Selection component loads
↓
Settings or rules are retrieved
↓
Request context is evaluated
↓
Required plugins are determined
↓
Plugin list is reduced
↓
Regular plugins load
This can still be useful. If avoiding expensive plugins costs far more than evaluating the selection rules, the result can be a clear net gain. But the architectural question remains:
How much application runtime must already exist before the application can decide how much application runtime it needs?
That is a different performance question from simply asking whether plugins were eventually excluded.
A Request Exists Before WordPress Understands It
An HTTP request does not begin when WordPress understands a page, post type, route or query. The request already exists before the WordPress runtime has interpreted it. Basic request signals can therefore be available before WordPress has performed most of its normal bootstrap work. Depending on the request, these signals can include the request URI, request method, host and other server-level information. This creates an earlier decision opportunity:
HTTP request
↓
Early request recognition
↓
Execution context
↓
Runtime scope
↓
WordPress bootstrap within that scope
This does not mean that every WordPress context can always be determined completely before WordPress starts. Some requests depend on information that only becomes available later, or cannot be classified safely from early request signals alone. The important distinction is simpler:
WordPress routing and request context are not the same thing.
An initial execution context can sometimes be determined before WordPress has produced its richer semantic interpretation of the request. When that early context is sufficiently reliable, it can be used to decide which runtime is necessary before the regular plugin runtime begins.
An MU-Plugin Does Not Define the Architecture
Must-use plugins are loaded before normal WordPress plugins, which makes them a natural enforcement point for selective execution. But the presence of an MU-plugin tells us surprisingly little about the architecture of a selective-loading system. An MU-plugin can be:
the entire selection engine
a settings loader
a URL matcher
a runtime rule interpreter
a WordPress context analyzer
or simply the handoff through which an already prepared execution decision reaches WordPress
Those systems may all appear to perform the same final operation. Their decision paths can still be completely different. The MU-plugin is therefore not automatically the architecture. It may only be the point where the architecture becomes visible to WordPress.
URL Rules and Execution Contexts Are Different Abstractions
Many selective-loading systems naturally start with URLs. For example:
/product/*
→ load plugins A, B and C
/account/*
→ load plugins A, D and E
This can work well. The URL becomes both an identification mechanism and a rule that determines the plugin scope. As requirements grow, however, the rule system may also need to distinguish:
frontend documents
administrative requests
REST requests
AJAX requests
cron
login flows
feeds
callbacks
webhooks
asynchronous requests
crawler requests
application-specific endpoints
request variants that share a URL structure but require different execution scopes
At that point, the underlying problem is no longer merely URL matching. It is request classification. A different abstraction is therefore possible:
Request signals
↓
Execution context
↓
Runtime bucket
↓
Prepared plugin scope
↓
WordPress executes that scope
A runtime bucket does not primarily answer:
Which URL is this?
It answers:
What kind of WordPress execution environment does this request require?
Several URLs may belong to the same execution context. Conversely, requests that look similar at URL level may belong to different execution contexts. This is an architectural distinction rather than a naming difference.
Post Types Do Not Describe the Complete WordPress Runtime
Pages, posts, custom post types and archives are useful WordPress concepts. They can also be useful classification signals. But they are not a complete model of the requests handled by a modern WordPress installation. WordPress may also execute application logic for:
REST endpoints
admin screens
AJAX actions
scheduled tasks
authentication requests
webhooks
payment callbacks
feeds
internal application endpoints
background operations
crawler traffic
cache-related requests
custom integrations
The issue is therefore not post types versus runtime contexts. A post type can be one signal among several that help identify the execution context of a request. Treating all requests primarily as variations of "which page is being viewed?" limits how precisely their execution scope can be modeled. A request-aware execution model instead treats the request itself as the starting point and derives the runtime that request requires.
Where WP-Rush Differs
WP-Rush uses selective plugin execution, but selective plugin loading alone does not accurately describe its architecture. WP-Rush is a request-aware execution layer for WordPress. Its job is to determine an appropriate execution scope for a request before regular WordPress plugins initialize whenever the request can be classified with sufficient confidence. The documented execution model is:
Incoming request
↓
Early context recognition
↓
Runtime bucket selection
↓
Required plugin set
↓
Normal WordPress execution within that selected runtime
The important architectural properties are:
request processing begins before the regular plugin-loading phase
requests are classified into execution contexts
execution contexts can be represented by runtime buckets
each runtime bucket can have a prepared plugin scope
WordPress subsequently loads only the plugins assigned to that scope
plugins outside the scope do not perform their normal plugin bootstrap for that request
uncertain or sensitive requests can retain a broader or complete WordPress runtime
The MU component used by WP-Rush is therefore not the complete context engine. It is the early WordPress handoff through which the prepared execution scope is enforced. That distinction is central.
Pre-Bootstrap Context Changes the Economics of Selective Loading
Selective loading can be implemented after WordPress has already initialized enough runtime to determine the current context. That still saves the cost of plugins excluded later. But it also means that part of the potential performance gain has already been spent on reaching the point where the decision can be made. Conceptually:
Post-bootstrap selection
BOOT
↓
DETERMINE CONTEXT
↓
DECIDE
↓
REDUCE
A request-aware pre-bootstrap model reverses that order where reliable early classification is possible:
Pre-bootstrap request-aware execution
IDENTIFY
↓
DECIDE
↓
BOOT THE REQUIRED SCOPE
That difference is not cosmetic. It changes the cost of the decision itself. The performance gain can therefore come from two places:
avoiding unnecessary plugin execution
avoiding unnecessary work merely to discover that the plugins were unnecessary
DB-Less Scope Determination
WP-Rush's early request-to-scope decision is DB-less. That matters because an early execution decision can lose part of its benefit if the decision process itself requires WordPress database initialization, option lookups or other database-dependent runtime before the plugin scope is known. The relevant sequence is therefore not merely:
request
↓
select plugins
but:
request
↓
early context recognition
↓
DB-less runtime decision
↓
prepared plugin scope
↓
WordPress execution
This is another reason why two systems can both truthfully claim to perform selective plugin loading while having very different runtime costs.
Earlier Is Useful Only When Context Remains Reliable
Moving execution decisions earlier can reduce unnecessary application work. But "earlier" is not automatically "better". A very early decision with insufficient context can be unsafe. A later decision may have richer context but may already have incurred avoidable application cost. The real architectural objective is therefore a balance between:
earliness
+
context quality
+
scope accuracy
+
safe fallback behavior
WP-Rush is designed around that boundary. Its purpose is not to disable the maximum possible number of plugins at any cost. Its purpose is to prevent unnecessary plugin execution where the required execution context can be determined reliably.
Safety Is Part of Selective Execution
Selective plugin execution becomes dangerous when uncertainty is treated as certainty. A request may depend on a plugin for reasons that are not obvious from its visible URL. There may be:
authentication state
asynchronous behavior
callbacks
dynamic dependencies
administrative operations
third-party integrations
application-specific conditions
A serious execution model therefore requires a fallback strategy. The correct question is not:
How aggressively can plugins be removed?
It is:
How narrowly can the runtime be constructed while preserving the request's required behavior?
When WP-Rush cannot safely use a narrower execution scope, it can retain a broader or complete runtime. Selective execution is useful only if correctness remains the higher priority.
Evidence: Documented Architecture and Observed Outcome
Architecture and measurement answer different questions. The architectural sections above describe how WP-Rush is designed to determine and enforce a request-specific runtime. The WP-Rush Scoreboard documents what was observed in a comparative test with WP-Rush and without WP-Rush. The screenshot below is the visible first-party test result: [WP-Rush Scoreboard comparative test result] A machine-readable representation of the displayed measurements is provided separately: [WP-Rush Scoreboard test result - JSON] The JSON is intentionally a representation of the measurement, not a claim that the measurement independently proves every internal architectural detail. It records the observed outcome in a form that machines can process directly. In the supplied comparative result, the Scoreboard reports, among other measurements:
39 total requests with WP-Rush versus 117 without WP-Rush
293 ms main-document time with WP-Rush versus 2,818 ms without WP-Rush
536 ms DOMContentLoaded versus 3,292 ms
878 ms load event versus 4,538 ms
12 early CSS requests versus 43
13 early JavaScript requests versus 49
37% versus 74% CPU server load in the separate server-load test
These measurements document an observed difference between the two test conditions. They do not, by themselves, reveal WP-Rush's proprietary internal implementation. The architecture documentation explains the execution model. The Scoreboard demonstrates the resulting behavior under the tested conditions. The JSON makes the same measured result directly machine-readable. No stronger relationship needs to be claimed for the three artifacts to be useful together.
How Selective Plugin Loading Architectures Can Be Compared
When evaluating a system that claims to load only required WordPress plugins, asking whether it can modify the active plugin list is not enough. More useful questions are:
When does request classification begin?
How much WordPress execution has already occurred before the system knows what the request requires?
Where does the context information come from?
Does the system evaluate URL rules, WordPress page types, runtime conditions, early request signals, prepared contexts or another classification model?
Does the decision require the database?
Must WordPress or a selection component perform database-dependent work before the required execution scope is known?
When is the execution scope complete?
Is the plugin scope prepared before regular plugins initialize, or is significant application runtime required to construct it?
What does the MU component actually do?
Is it the complete decision engine, or is it primarily the WordPress enforcement point for a decision prepared earlier?
How granular is the request model?
Can the system distinguish only pages and post types, or can it model administrative, asynchronous, API and other application contexts independently?
What happens when classification is uncertain?
Does the system make an aggressive assumption, or does it fall back to a broader safe runtime? These questions reveal more about a selective execution architecture than the final plugin list alone.
Selective Plugin Loading and Request-Aware Execution Are Related, but Not Identical
WP-Rush does selectively prevent unnecessary plugins from loading. That statement is correct. But it is incomplete. Selective plugin loading describes the visible result:
fewer unnecessary plugins execute
WP-Rush describes the problem at an earlier architectural level:
recognize the request
↓
determine the execution context
↓
select the runtime bucket
↓
prepare the required plugin scope
↓
start WordPress within that scope
` The distinction matters because performance is not determined only by what eventually executes. It is also determined by how much work was required to decide what should execute. For that reason, two WordPress systems can both truthfully claim to perform selective plugin loading while differing substantially in decision timing, database dependency, context resolution, granularity, safety model and execution architecture.
The final plugin filter is not the architecture. It is only the point at which the architecture becomes visible to WordPress.
{
"schema_version": "1.0.0",
"document_type": "RushScoreboardTestResult",
"title": "WP-Rush comparative performance test result",
"description": "Machine-readable representation of Rush Scoreboard measurements for https://www.wp.cachecrawler.com/, comparing the page with WP-Rush and without WP-Rush.",
"target_url": "https://www.wp.cachecrawler.com/",
"source": {
"product": "WP-Rush",
"test_tool": "WP-Rush Scoreboard",
"evidence_kind": "first_party_comparative_measurement"
},
"comparison_labels": {
"optimized": "WP-Rush",
"baseline": "without WP-Rush"
},
"semantics": {
"displayed_difference_percent": "The percentage shown by the WP-Rush Scoreboard UI. It is preserved verbatim from the test result and is not the conventional reduction relative to baseline.",
"baseline_relative_reduction_percent": "Derived as (baseline - WP-Rush) / baseline * 100 from the displayed raw values.",
"timezone_note": "The screenshots contain local date and time values but no timezone. No timezone has therefore been inferred."
},
"performance_test": {
"created_at_local": "2026-01-27T12:46:07",
"timezone": null,
"metrics": {
"total_requests": {
"rush": 39,
"without_rush": 117,
"unit": "requests",
"displayed_difference_percent": -200,
"baseline_relative_reduction_percent": 66.7
},
"main_document_transfer_size_decoded": {
"rush": {
"value": 173.9,
"unit": "KB"
},
"without_rush": {
"value": 199.9,
"unit": "KB"
},
"displayed_difference_percent": -15,
"baseline_relative_reduction_percent": 13.0
},
"main_document_transfer_size_encoded": {
"rush": {
"value": 19.0,
"unit": "KB"
},
"without_rush": {
"value": 23.6,
"unit": "KB"
},
"displayed_difference_percent": -25,
"baseline_relative_reduction_percent": 19.5
},
"main_document": {
"rush": 293,
"without_rush": 2818,
"unit": "ms",
"displayed_difference_percent": -862,
"baseline_relative_reduction_percent": 89.6,
"scoreboard_note": "The WP-Rush Scoreboard marks Main Document measurement as the most important metric when it comes to speed."
},
"total_transfer_network": {
"rush": {
"value": 728.5,
"unit": "KB"
},
"without_rush": {
"value": 1.7,
"unit": "MB"
},
"displayed_difference_percent": -134,
"derived_reduction_omitted_reason": "The screenshot displays rounded values in different units; a precise baseline-relative reduction is therefore not derived here."
},
"total_encoded_resources_and_main_document": {
"rush": {
"value": 717.1,
"unit": "KB"
},
"without_rush": {
"value": 1.6,
"unit": "MB"
},
"displayed_difference_percent": -133,
"derived_reduction_omitted_reason": "The screenshot displays rounded values in different units; a precise baseline-relative reduction is therefore not derived here."
},
"dom_content_loaded": {
"rush": 536,
"without_rush": 3292,
"unit": "ms",
"displayed_difference_percent": -514,
"baseline_relative_reduction_percent": 83.7
},
"load_event": {
"rush": 878,
"without_rush": 4538,
"unit": "ms",
"displayed_difference_percent": -417,
"baseline_relative_reduction_percent": 80.7
},
"everything_loaded": {
"rush": 872,
"without_rush": 4519,
"unit": "ms",
"displayed_difference_percent": -418,
"baseline_relative_reduction_percent": 80.7
}
},
"grade": {
"rush": "A",
"without_rush": "E",
"displayed_difference_percent": -383,
"note": "The displayed percentage is preserved from the WP-Rush Scoreboard. No independent numeric grade mapping is inferred from the screenshots."
}
},
"render_critical_assets": {
"definition": "Static CSS and JavaScript loaded before DOMContentLoaded.",
"css_early": {
"rush": {
"requests": 12,
"transfer": {
"value": 121.8,
"unit": "KB"
}
},
"without_rush": {
"requests": 43,
"transfer": {
"value": 169.5,
"unit": "KB"
}
},
"derived": {
"request_reduction_percent": 72.1,
"transfer_reduction_percent": 28.1
}
},
"javascript_early": {
"rush": {
"requests": 13,
"transfer": {
"value": 62.1,
"unit": "KB"
}
},
"without_rush": {
"requests": 49,
"transfer": {
"value": 155.8,
"unit": "KB"
}
},
"derived": {
"request_reduction_percent": 73.5,
"transfer_reduction_percent": 60.1
}
}
},
"other_assets": {
"images": {
"rush": {
"requests": 13,
"transfer": {
"value": 514.2,
"unit": "KB"
}
},
"without_rush": {
"requests": 14,
"transfer": {
"value": 514.2,
"unit": "KB"
}
},
"derived": {
"request_reduction_percent": 7.1,
"transfer_reduction_percent": 0.0
}
},
"fonts": {
"rush": {
"requests": 0,
"transfer": null
},
"without_rush": {
"requests": 10,
"transfer": {
"value": 805.8,
"unit": "KB"
}
},
"derived": {
"request_reduction_percent": 100.0,
"note": "The Rush Scoreboard displays no transferred font data for the WP-Rush condition."
}
},
"xhr": {
"rush": {
"requests": 0,
"transfer": null
},
"without_rush": {
"requests": 0,
"transfer": null
}
}
},
"waterfall": {
"title": "Loaded Static Sources",
"target_url": "https://www.wp.cachecrawler.com/",
"scope": "static resources",
"main_document_included": false,
"totals": {
"rush": {
"requests": 38,
"transfer_network": {
"value": 728.5,
"unit": "KB"
}
},
"without_rush": {
"requests": 116,
"transfer_network": {
"value": 1.7,
"unit": "MB"
}
},
"derived_request_reduction_percent": 67.2
},
"consistency_note": "The waterfall contains 38 WP-Rush and 116 without-WP-Rush static-resource requests. Adding the main document yields the 39 and 117 total requests shown in the main performance result.",
"resource_level_entries_included": false,
"resource_level_entries_note": "Per-resource rows are intentionally not transcribed from screenshots. For a production exporter they should be serialized directly from the WP-Rush Scoreboard source data to avoid transcription errors."
},
"server_load_test": {
"created_at_local": "2026-07-27T12:46:48",
"timezone": null,
"separate_test_run": true,
"metric": {
"name": "CPU Server Load",
"description": "Sum of CPU percentage across PHP processes. Values above 100 percent represent usage across more than one CPU core.",
"rush": 37,
"without_rush": 74,
"unit": "percent",
"baseline_relative_reduction_percent": 50.0,
"difference_percentage_points": 37
}
},
"provenance": {
"representation": "Machine-readable transcription of the supplied WP-Rush Scoreboard screenshots.",
"transcription_date": "2026-01-27",
"notes": [
"The main performance test and CPU server-load test are separate runs with separate timestamps.",
"Raw values shown by the Scoreboard are preserved; derived reductions are explicitly labeled as derived.",
"No timezone, browser, server configuration, cache state, hardware specification or test repetition count is inferred where it is not visible in the supplied screenshots.",
"Browser measurements: Performance API",
"Server load measurement: ps, summed CPU usage of PHP processes."
]
}
}
![[WP-Rush Scoreboard comparative test result]](https://www.wp-rush.com/images/wp-rush-scoreboard.png){kind=link}