# Chapter #5: Optimization, Caching and Prevention ## Three different strategies for reducing execution cost. WordPress performance can be viewed as three complementary strategies. **Optimization** Optimization does not reduce the work WordPress performs. It adds post-processing to improve the generated output. **The original execution cost has already been created.** **Caching** Caching reduces how often work has to be repeated. A previously generated result can be reused instead of rebuilding it for every identical request. This can produce enormous performance gains. But whenever the cache cannot answer the request, WordPress still has to execute the application. **Prevention** Prevention addresses a different question. Instead of asking how to make existing work cheaper or how to reuse its result, it asks whether some of that work needs to exist for this request at all. **Prevention prevents unnecessary work from creating cost.** These approaches are not competitors. They operate at different points in the architecture and can complement each other.### WordPress performance is often discussed as if every speed improvement belonged to the same category. **It does not.** Optimization, caching and prevention can all improve performance, but they act on different problems and at different stages of the request lifecycle. Understanding that distinction matters because the visible result may be similar while the underlying mechanism is fundamentally different.### Optimization changes the result after work has happened In the WordPress ecosystem, optimization usually means post-processing. - The application has already executed. - PHP has already run. - Plugins have already participated. - Queries may already have been performed. - The response already exists. - Optimization then modifies that result. - It may reduce HTML, minify assets, defer scripts, rewrite resources or otherwise improve delivery and browser behavior. This can make the page faster for the visitor. But it does not reduce the application work that created the response. In fact, the optimization process itself requires additional processing. Optimization changes the result of work that has already happened. Its benefit lies downstream from the original execution cost.### Caching avoids repeating work Caching addresses a different problem. Instead of changing the generated result, it stores a result so that the same work does not have to be repeated unnecessarily. A full-page cache can be particularly effective. When a valid cached response already exists, the cache can answer the request before WordPress executes. For that request, the application cost is avoided almost completely. This is one of the strongest performance mechanisms available to WordPress. But caching depends on reuse. A cache can only return a response that already exists and is valid for the current request. When no suitable cached response exists, WordPress still has to execute. The same applies to requests that are dynamic, personalized, administrative or otherwise unsuitable for full-page caching. Caching therefore answers: **Can we avoid executing the application again by reusing a previous result?** It does not answer: **How much of the application should participate when execution is necessary?**### Prevention acts before unnecessary work begins Prevention addresses that earlier question. When WordPress must execute, prevention asks whether every available part of the application needs to participate in the current request. If the required execution scope can be determined early enough, unnecessary application work does not have to enter the runtime at all. This is not post-processing. And it is not result reuse. It is an execution decision. **Prevention keeps unnecessary work from being created in the first place.** That distinction is important because work that never begins does not need to be optimized, cached or processed later.### Caching and prevention solve different problems Caching and prevention can look similar because both can reduce PHP execution. But they do so in very different ways. A cache says: **This result already exists. Do not execute WordPress.** Prevention says: **WordPress must execute. Determine how much of the application this request actually needs.** On a successful full-page cache hit, prevention has little or nothing to contribute because WordPress is already bypassed. On a cache miss, an uncached request or a request that cannot safely use a shared page cache, application execution becomes unavoidable. That is where prevention becomes relevant. Caching determines whether the application must run. Prevention determines the execution scope when it does.### Prevention has its own cost Prevention is not free. Determining request context and execution scope requires work. That work must therefore happen early and cheaply enough to justify itself. If the decision process costs more than the execution it avoids, prevention has failed as a performance strategy. This creates a strict requirement: **The cost of deciding must be lower than the cost of unnecessary execution prevented by that decision.** That is also why request-aware prevention cannot simply wait for the full WordPress runtime to provide all possible context. If WordPress has already created most of the application environment before the decision is made, much of the preventable cost already exists. Prevention depends not only on making the correct decision. It depends on making it at the correct intervention point.### The three strategies are complementary Optimization, caching and prevention should not be treated as competing philosophies. They operate on different layers. - **Optimization** improves the produced result after application work has occurred. - **Caching** avoids repeating application work when a reusable result already exists. - **Prevention** avoids unnecessary application work when execution is required. A WordPress site can benefit from all three. A cached response may be delivered without WordPress. A cache miss may execute only the application scope required by the request. The resulting response may still be optimized for delivery and rendering. Each technique acts where the previous one can no longer help.### Performance architecture is about placing work correctly The important question is therefore not which technique is universally best. It is which problem exists at which point in the request lifecycle. If a response can be reused, caching is difficult to beat. If WordPress must execute, unnecessary application scope should not become unavoidable merely because the request was not cacheable. And once the response has been produced, output optimization can still improve what happens between server and browser. The strategies form a sequence: - Reuse existing results when possible. - Prevent unnecessary execution when application work is required. - Optimize the resulting output where useful. This is a broader performance architecture than treating every speed improvement as optimization. And it leads directly to the remaining architectural question: **If prevention depends on deciding execution scope before unnecessary work begins, where does that decision belong?**### Three different strategies for reducing execution cost.