# Chapter #3: Necessary Work vs. Unnecessary Work

## Why application size alone tells us little about what a particular request actually needs.

Not all execution is waste. A request needs work in order to produce a result. A WooCommerce checkout request may legitimately require cart handling, sessions, payment integrations, tax logic and other commerce functionality. A simple article request may not.   
  
 The performance question is therefore not whether WordPress should execute less code in general.   
  
 It is: **Which code actually needs to participate in this request?**   
  
 This distinction creates two categories of runtime work.   
  
 **Necessary work** contributes to the correct result of the request.   
 **Unnecessary work** participates in the runtime even though the request does not require its functionality.   
  
 Traditional optimization can make both categories cheaper. Architecture can distinguish between them. That distinction matters because optimizing unnecessary work does not make it necessary.### A WordPress request always requires work.

The goal of performance architecture is not to eliminate execution. It is to distinguish between work that contributes to the correct result of the request and work that does not.   
  
 **That distinction is fundamental.**   
  
 Because a fast application is not one that does nothing. It is one that avoids doing what the current request does not require.### Necessary work is request-specific

Necessary work cannot be defined globally.   
  
 The same plugin can be essential for one request and irrelevant for another. A checkout request may genuinely require: - cart handling
- session state
- payment logic
- tax calculation
- shipping methods
- inventory checks
 
 A simple article request may require none of them. The plugin itself has not changed.   
  
 The request has.   
  
 This means that necessity is not primarily a property of a plugin. It is a property of the relationship between functionality and request context.   
  
 **Request-specific execution does not mean asking the fully initialized WordPress application what the request needs. For this distinction to reduce execution, request context must be recognizable before the unnecessary application scope has already been created. Otherwise, determining necessity can itself become part of the work we intended to avoid.**### Unnecessary work is not the same as bad code

This distinction is easy to miss.   
  
 Unnecessary work does not necessarily mean inefficient work. A plugin may be well written. - Its code may be fast.
- Its queries may be efficient.
- Its internal logic may be perfectly reasonable.
- And yet its participation can still be unnecessary for a particular request.
 
 That is an architectural issue rather than a code-quality issue.   
  
 The question is not: **Is this code efficient?**   
  
 The earlier question is: **Does this request need this code to participate at all?**   
  
 Efficient execution and necessary execution are two different properties.### Application scope and request scope are different

A WordPress installation may contain a large number of capabilities.   
  
 Commerce, analytics, forms, SEO, redirects, memberships, marketing systems, administrative tools and external integrations can all belong to the same application.   
  
 **That defines the application scope.**   
  
 But an individual request usually needs only part of that scope.   
  
 **That defines the request scope.**   
  
 The larger the difference between the two, the greater the opportunity for unnecessary work to occur. A complex application does not therefore have to produce a complex runtime for every request. Complexity belongs to the application. Execution belongs to the request.   
  
 Those should not automatically be treated as the same scope.### Visible output does not reveal necessity

A common mistake is to judge required functionality from the visible page alone.   
  
 **That is not sufficient.**   
  
 A plugin may perform necessary work without producing visible HTML. Security checks, authentication, routing, cache coordination, access control or application state may all be essential even when nothing appears in the rendered page.   
  
 **The opposite is also true.**   
  
 A plugin can participate heavily in a request without contributing anything necessary to the final result. Necessity therefore cannot be inferred simply by looking at the frontend.   
  
 It must be determined from request context and application requirements.### Necessary work is defined by correctness

Performance cannot come before correctness.   
  
 If removing a component changes the intended result, breaks required functionality or invalidates application state, that component was part of the necessary execution scope. The objective is not the smallest possible runtime at any cost.   
  
 It is the smallest runtime that still produces the correct result.   
  
 That boundary matters.   
  
 Without it, selective execution becomes guesswork. With it, unnecessary work becomes a technically meaningful category.### The cost of scope mismatch

When application scope is larger than request scope, the runtime can include functionality that contributes nothing to the request. One unnecessary participant may not matter.   
  
 Dozens can.   
  
 This is how a site can produce significant server-side execution for a response that appears trivial from the outside. The problem is not simply that the application is large.   
  
 The problem is that too much of the application may participate in a request whose actual requirements are small. That difference can be described as a **scope mismatch.**   
  
 The greater the mismatch, the more unnecessary work can exist.### Performance needs a notion of necessity

Traditional WordPress execution knows very well which plugins are active.   
  
 What it usually does not know early enough is which of them are necessary for the current request. Without that distinction, active functionality becomes the practical execution scope.   
  
 A performance architecture needs a different model:   
  
 **Application scope defines what is available.**   
 **Request scope defines what is necessary.**   
  
 Only when these are separated can unnecessary work be identified before it becomes execution cost. That leads directly to the next architectural question:   
  
 At what point in the request lifecycle can that distinction still make a difference?### Why application size alone tells us little about what a particular request actually needs.