# Chapter #2: How WordPress Creates Work ## How loading, initialization and request-specific execution contribute different types of runtime cost. It is tempting to describe the problem simply as "WordPress is bloated." That is too crude. WordPress Core itself is not necessarily responsible for the majority of execution cost on a complex site. Removing small Core features, metadata, markup or frontend conveniences can reduce output without producing a comparable reduction in server-side execution. The deeper issue is architectural. WordPress provides the runtime in which extensions participate. Plugins can load files, instantiate objects, register hooks, inspect configuration, establish integrations and prepare functionality long before WordPress reaches the part of the request where their actual relevance becomes clear. Each individual operation may be inexpensive. But application cost is cumulative. A larger WordPress installation therefore does not become expensive only because individual plugins are badly optimized. It can also become expensive because more and more functionality participates in requests for which only part of that functionality is needed. The architecture allows unnecessary work to accumulate. So the problem is not simply: **WordPress contains too much.** It is more accurately: **WordPress commonly makes functionality available before the necessity of that functionality has been established for the current request.**### A WordPress request does not begin with the final page. It begins by constructing an application environment capable of producing that page. WordPress Core establishes the runtime, loads configuration, initializes its subsystems and provides the mechanisms through which themes and plugins can participate. From there, every active extension can add its own work to the request. This is how application availability becomes execution cost.### Work begins before visible functionality A plugin does not need to produce visible output in order to create work. Before a shortcode is rendered, a form appears or a shop function is used, the plugin may already have participated in the request. Typical work includes: - loading PHP files - initializing classes and objects - registering hooks and filters - reading configuration and options - checking request conditions - establishing integrations - preparing services or dependencies - performing database queries - attaching functionality for later execution Some of these operations are extremely small. But they still belong to the request. And they happen before the final response tells us which functionality was actually visible or used.### WordPress Core is not necessarily the main source of cost This distinction matters. It is easy to assume that WordPress performance problems originate primarily from WordPress Core itself. But reducing Core-generated markup, disabling small built-in features or removing miscellaneous frontend output often produces only modest changes in server-side execution. The generated page may become smaller while PHP execution, memory use and database activity change surprisingly little. That tells us something important: **The architecture can be responsible for the performance problem without WordPress Core itself being responsible for most of the resulting workload.** Core provides the runtime. Extensions populate it. The cost emerges from what participates in that runtime.### Small costs accumulate A single plugin may add only a few milliseconds. - Another may add a little memory. - Another may read several options. - Another may initialize an integration. - Another may register dozens of callbacks that never execute during the request. None of these operations has to be individually catastrophic. The important property is accumulation. A WordPress installation with many extensions does not create one large block of additional work. It creates many small pieces of work that become part of the same request lifecycle. The total execution cost is therefore not determined only by the slowest component. It is also determined by how many components participate at all.### Activation defines availability WordPress activation is primarily a site-level concept. Once a plugin is active, WordPress normally treats it as part of the application environment. That does not mean every plugin performs its most expensive operation on every request. Good plugins often contain their own conditional logic. But that conditional logic usually exists inside the plugin. The plugin therefore has to become part of the runtime before it can decide that no further action is required. This creates an important distinction: **Doing nothing later is not the same as never having participated.** A plugin can correctly conclude that a request does not require its functionality and still have created work in reaching that conclusion.### The runtime grows with the application This is why WordPress performance can deteriorate as an installation grows even when the visible page remains simple. The page may contain little content. The browser may receive only a small document. Yet the server may have constructed a much larger application environment before producing it. The visible complexity of a response and the execution complexity behind that response are not the same thing. A simple URL can still traverse a large runtime.### From availability to work The WordPress Performance Dilemma begins with broad availability. This is how that availability becomes real execution: - **WordPress establishes the runtime.** - **Active extensions enter that runtime.** - **Each extension can introduce initialization and execution cost.** - **Those costs accumulate within the request.** Only after understanding how this work is created does the next question become meaningful: How much of that work was actually necessary for the request?### How loading, initialization and request-specific execution contribute different types of runtime cost.