DEV Community: Andy Kirchbühler

WordPress, 404s, and the Cost of a Typo

Andy Kirchbühler — Fri, 18 Sep 2026 09:47:08 +0000

WordPress, 404s, and the Cost of a Typo

A request arrives at a WordPress site.

The URL does not exist.

At that point, you might expect the web server to reject it and move on.

Instead, WordPress can do a surprising amount of work before it can confidently say:

404. Nothing here.

That always bothered me.

Not because 404 pages are unusual. They are part of the web.

What bothers me is the amount of machinery that may be involved in producing an answer that, in many cases, could have been known much earlier.

And there is a second problem hiding behind the first one.

Sometimes the requested resource actually does exist.

Only the URL is slightly wrong.

One missing letter can be enough to turn perfectly valid intent into a dead end.

That combination made me wonder whether WordPress handles some requests too late.

A 404 is not always a cheap answer

WordPress is an application, not a static file server.

That distinction matters.

When a request reaches WordPress, the application needs context before it can decide what the request means.

Routing happens. Rewrite rules are evaluated. The request is parsed. Plugins may load. The theme may become involved. Database queries may happen.

Eventually WordPress reaches a conclusion:

There is no matching resource.

The response becomes a 404.

From the visitor's perspective, that sounds simple.

From the server's perspective, it may not have been simple at all.

This becomes especially wasteful when the request was obviously useless from the beginning.

Think about automated probes, malformed URLs, abandoned paths, random scanner traffic, old links, broken bots and requests for resources that have never existed on the site.

The application spends resources discovering the absence of something.

That feels backwards.

If the answer can already be established before the CMS is fully involved, why boot the CMS just to confirm it?

The usual performance discussion starts too late

Most WordPress performance work focuses on making execution cheaper.

Caching, object caching, CDNs, database tuning, PHP tuning and asset optimization all have their place.

But they usually start with the same assumption:

The request should reach WordPress.

That is the part I started questioning.

There is a difference between making work faster and avoiding unnecessary work altogether.

If a request can safely be identified as irrelevant before WordPress has to process it, then the fastest version of that request is not an optimized WordPress request.

It is a request WordPress never had to handle.

Then there is the opposite problem

Rejecting useless requests early sounds straightforward.

But there is a trap.

Not every incorrect URL represents incorrect intent.

Assume this is a valid page:

/example-title/

Now somebody links to:

/exampl-title/

One letter is missing.

The visitor's intention may still be obvious to a human.

The resource still exists.

But the path no longer identifies it reliably.

If WordPress cannot determine which resource was intended, the request ends in a 404.

And that exposes another form of waste.

The first kind wastes server resources.

The second kind wastes traffic.

A visitor, search engine, external website, bookmark, email or automated system may be trying to reach a real resource. A damaged or outdated path can break that connection completely.

Simply rejecting unknown requests earlier would therefore solve only half of the problem.

Some requests should be rejected.

Some should be recovered.

The problem is identity

A typical WordPress permalink can look like this:

/example-title/

It is nice to read.

It tells humans something about the resource.

But it also has to identify the resource.

Those are two different jobs.

Preflight separates them.

For a Post, a Preflight URL can look like this:

/example-title/:-:123/

The first part is still semantic:

example-title

Then comes a delimiter:

:-:

And after that comes the stable resource ID:

123

The readable part describes the resource.

The ID identifies it.

That distinction changes what can happen when a URL gets damaged.

What happens when somebody makes a typo?

Take the canonical Preflight URL:

/example-title/:-:123/

Now imagine that an external site accidentally publishes this instead:

/exampl-title/:-:123/

The semantic part is wrong.

But the resource identity is still there.

123

Preflight does not have to guess that "exampl" probably meant "example".

It does not need fuzzy matching.

It can identify resource 123 directly.

It can then compare the requested path with the current canonical path and see that they do not match.

The result can be a permanent redirect:

301 -> /example-title/:-:123/

The typo never becomes the identity of the resource.

And the visit does not have to disappear into a 404.

That is the part I find important.

This is not typo correction in the usual sense.

Preflight is not trying to be clever about spelling.

The semantic part can be wrong while the stable part still says exactly which resource was requested.

It also works when the URL simply gets old

Typos are only the obvious example.

Imagine the resource title or slug changes later.

The old URL might be:

/my-old-title/:-:123/

The current canonical URL might now be:

/my-new-title/:-:123/

The wording changed.

The identity did not.

That means an old external link can still carry enough information to identify the intended resource and reach its current canonical URL.

The human-readable part of the URL is allowed to evolve without becoming the only source of truth about what the URL points to.

This is a fairly old idea in computing.

What interested me was applying it to WordPress not only for URL resilience, but also for request qualification.

Stable identity makes earlier decisions possible

Once public resources have an identity that can be recognized without relying entirely on WordPress resolving an arbitrary semantic path, another possibility appears.

You can ask useful questions earlier.

Is this a known resource?

Does it still exist?

Does the requested semantic path match its canonical path?

Is this request valid enough to justify handing it to WordPress?

Or is there already enough information to produce the correct response?

That is where the performance side and the URL side of Preflight meet.

The resource ID is not there merely to make unusual-looking URLs.

It provides a deterministic piece of information that can be evaluated before the normal WordPress request lifecycle has done all of its work.

That became Preflight

I called the experiment Preflight because that is essentially what it does.

Before a request is handed to the full WordPress application, perform a lightweight qualification.

Not a replacement router.

Not another cache.

Not a second CMS.

Just an early decision layer in front of the expensive one.

A valid request can continue normally.

A known resource with an incorrect or stale semantic path can be redirected to its canonical URL.

A resource known to be gone can be handled accordingly.

An invalid request can be rejected early.

And when Preflight cannot make a reliable decision, WordPress remains the fallback.

That last point matters.

Early handling only makes sense when uncertainty does not break normal application behavior.

Preflight should act when it knows.

Not when it guesses.

There is another expensive corner: missing static files

There is a related case that is easy to overlook.

A missing image, CSS file, JavaScript file or font can also fall through the normal WordPress rewrite path on some setups.

At that point the server may end up starting WordPress merely to discover that a static file does not exist.

That is an impressive amount of software to answer a very small question.

Preflight treats static files differently from resources such as Posts, Terms and Authors. They do not need the same identity model.

Where the server configuration allows it, missing static resources can be finished at the web-server level instead of falling through to the normal WordPress front controller.

Again, the principle is the same:

Do not start the application when the answer does not require the application.

WordPress is not doing anything irrational

Its architecture makes sense within the assumptions it was built around.

The application receives a request and figures out what that request means.

The question is whether every request reaching a modern public WordPress installation still deserves that treatment.

Bots probe arbitrary URLs.

Scanners try common files.

Old paths survive for years.

Links get copied incorrectly.

Automated systems invent paths.

Humans make typos.

Removed images remain referenced somewhere.

Yet many of those requests can enter the same application pipeline as a legitimate page view.

That is the part I find difficult to justify.

The application should be involved when application knowledge is required.

But when the answer is already known, executing the whole stack looks less like flexibility and more like unnecessary work.

Not every optimization has to optimize execution

This is probably the main thing I took away from building Preflight.

Performance discussions tend to focus on execution.

How quickly can PHP run?

How much can we cache?

How many queries can we remove?

How small can the page become?

Those are useful questions.

But there is another one:

Should this request cause application execution at all?

Sometimes the best query is the one that never runs.

Sometimes the fastest plugin is the one that never loads.

Sometimes the cheapest 404 is the one WordPress never has to discover.

And sometimes a broken-looking URL should not be a 404 at all.

If the stable identity still tells us which resource was intended, throwing that request away would be just as wasteful as processing an obviously invalid one through the entire application stack.

That is the idea behind Preflight.

Reject what is clearly invalid.

Recover what is still identifiable.

And involve WordPress when WordPress is actually needed.

https://wordpress.org/plugins/imedes-preflight/

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/