# Chapter #4: Intervention Points

## Why the point at which a performance technique acts determines what it can prevent.

Every performance technique operates at a particular point in the request lifecycle. That intervention point defines what the technique can influence. - A CDN can improve delivery.
- Frontend optimization can improve assets and rendering.
- Database optimization can reduce query cost.
- Object caching can avoid repeated data retrieval.
- Page caching can avoid repeated application execution for cacheable responses.
 
 All of these are valuable. But none can retroactively prevent costs that were already created before they intervened.   
  
 **A performance mechanism cannot prevent cost that has already been created before its intervention point.**   
  
 This is why two techniques that both make a website faster may still operate on fundamentally different architectural levels. The earlier a reliable decision can be made, the more work can potentially be avoided rather than merely optimized.### Every performance technique acts at a specific point in the request lifecycle.

That point determines what the technique can still influence.   
  
 This sounds obvious.   
  
 But many WordPress performance discussions compare methods by their visible result rather than by the moment at which they intervene.   
  
 A faster page is a faster page. Architecturally, however, the difference can be substantial.### Performance has a timeline

A simplified WordPress request can be viewed as a sequence:   
  
 **request ? cache decision ? WordPress bootstrap ? plugin execution ? application logic ? response generation ? post-processing ? delivery ? browser rendering**   
  
 Different performance mechanisms operate at different positions along that path. - A page cache may answer before WordPress runs.
- A plugin may alter behavior during WordPress execution.
- An optimization plugin may modify output after WordPress has generated it.
- A CDN may improve delivery.
 
 The browser may reduce rendering cost through caching or scheduling. All of these can improve perceived or measured performance.   
  
 But they do not act on the same work.### Earlier intervention changes what can be prevented

The later a technique intervenes, the more work has already happened. Once WordPress has loaded a plugin, the cost of loading that plugin already exists. Once PHP has executed a query, the cost of that query already exists.   
  
 Once the response has been generated, reducing its HTML size cannot undo the execution that produced it.   
  
 This leads to a simple architectural rule:   
  
 **A performance mechanism cannot prevent cost that was already created before its intervention point.**   
  
 It may still improve what happens afterwards. But the earlier work remains part of the request.### A cache intervenes before application execution

A full-page cache occupies a particularly early position.   
  
 If it already contains a valid response, it can return that response without requiring the WordPress application to execute at all. For that request, this is better than making WordPress faster.   
  
 WordPress is avoided.   
  
 That is why full-page caching can produce such dramatic gains. But the intervention only applies when the cache can answer the request. When it cannot, execution continues.   
  
 The next intervention point therefore becomes relevant.### WordPress itself is already an intervention boundary

Once the normal WordPress bootstrap begins, application scope starts to form.   
  
 Core is initialized.   
  
 Active plugins become available. Application behavior starts attaching itself to the request. Decisions made inside that runtime can still reduce later work.   
  
 But they cannot erase the work required to reach that point. This is why conditional execution inside WordPress and request classification before WordPress are architecturally different.   
  
 Both may be request-aware. They intervene at different times.### Post-processing intervenes after execution

Many tools described as WordPress optimization operate even later. - The application runs.
- The response is generated.
- Then additional processing modifies that response.
- HTML can be rewritten.
- Assets can be minified or deferred.
- Resources can be reorganized.
 
 This can improve transfer or browser behavior. But it cannot reduce the application work that has already produced the response.   
  
 Its intervention point is downstream from that cost.### Earlier is not automatically better

An early intervention point creates opportunity.   
  
 It does not guarantee correctness or efficiency. A decision made before WordPress has less application context available. The earlier the decision, the more carefully it must rely on information that is already trustworthy at that stage.   
  
 The decision itself also has a cost.   
  
 An early performance layer only makes sense when the cost of deciding is lower than the execution it can avoid. Otherwise, prevention becomes overhead.   
  
 So the goal is not: **intervene as early as possible.**   
  
 It is: **intervene as early as reliable decisions allow.**### Request context exists before WordPress

This distinction is especially important in WordPress. Request-aware behavior is often associated with WordPress APIs because those APIs provide convenient application context.   
  
 But the request itself exists before WordPress.   
  
 Its path, method, parameters, headers and other request characteristics are already present before the WordPress runtime has been constructed. Not every application decision can be made from that information.   
  
 But some can. This creates an intervention point that conventional WordPress execution rarely uses:   
  
 **between the incoming request and the broad application runtime.**   
  
 That is the architectural space in which execution scope can potentially be determined before unnecessary application work begins.### Intervention points define performance strategies

Performance techniques therefore differ not only by what they improve, but by where they act. A cache can avoid application execution when a reusable response already exists. WordPress-internal logic can influence work after the runtime has begun.   
  
 Post-processing can improve the generated result.   
  
 Delivery mechanisms can improve what happens after the application has finished. And an early execution decision can influence how much of the application enters the runtime in the first place.   
  
 These are different intervention points. They solve different parts of the performance problem. Only after distinguishing them does it make sense to compare the three broader strategies:   
  
 **Optimization, Caching and Prevention.**### Why the point at which a performance technique acts determines what it can prevent.