The WitsCode WordPress Build Manifesto: Performance Budget, Plugin Cap, Page Limit

A WordPress performance budget is a fixed, numerical set of constraints a site must meet before launch and continue to meet in production. It converts performance from a vague aspiration into a build-time gate that either passes or fails. We treat it the way structural engineers treat load limits. The number is the contract. The number does not bend because a stakeholder loves a slider.

We publish ours so prospective clients understand what they are buying when they hire WitsCode and so other WordPress builders feel free to steal the discipline. Three numbers govern every site we ship: 1.5 seconds Largest Contentful Paint at the 75th percentile of real-user data, no more than 12 active plugins, and no more than 80 kilobytes of CSS per page template after minification. Every other technical decision we make on a build orbits those three rules. They are early in this article on purpose. If you read nothing else, read those three.

Why we publish a manifesto instead of a feature list

Most WordPress agencies sell capabilities. They will list the page builders they support, the form plugins they integrate, the e-commerce platforms they configure. We have nothing against capabilities, but capabilities sold without constraints produce the kind of site every WordPress consultant ends up rebuilding two years later. A homepage carrying 4.2 megabytes, six tracking scripts, a slider plugin nobody uses, and an LCP of 4.1 seconds did not arrive that way through malice. It arrived through unconstrained agreement to every feature request that crossed the project manager's desk.

Constraints produce better sites than feature-stuffing because constraints force the trade-off conversation to happen early, in front of the client, before ten thousand dollars of design and development have accreted around a feature that should never have shipped. The manifesto is how we turn that conversation into something both parties can negotiate against. You want the rotating testimonial carousel? Wonderful. Tell us which of the existing twelve plugins gets retired to make room. You want the live Instagram feed on the homepage? Show us where it fits inside the 80-kilobyte CSS ceiling. Suddenly the conversation is honest.

Constraint one: 1.5 seconds Largest Contentful Paint

Google's Core Web Vitals threshold for a "good" LCP is 2.5 seconds at the 75th percentile of field data, measured through the Chrome User Experience Report. That is the floor below which Google starts counting your site as slow. We treat it as the failing grade, not the target. Our budget is 1.5 seconds, a full second under what Google considers acceptable, and we hold that target on a mid-tier $35-per-month managed host running real production data, not on a localhost demo with a stripped fixture database.

The reason is competitive arithmetic. The HTTP Archive Web Almanac consistently puts the median WordPress site somewhere around 3.0 seconds LCP on mobile. If we ship at 2.5 we are landing on the threshold of mediocre. If we ship at 1.5 we are sitting in the top decile of the platform, and that gap is felt by users, by search engines, and by every conversion metric that touches page speed. Deloitte's mobile site speed study, published with Google in 2020 and replicated since, found a 1 percent revenue lift on retail per 100 milliseconds of speed improvement. A second of LCP headroom is not a vanity metric. It is money.

The 1.5-second target is what we measure. The fallback rule, the thing we do when a build threatens to break the target, is to remove rather than optimize. We will pull a hero video before we will spend three days tuning a video plugin. We will replace a JavaScript-driven testimonial carousel with three static testimonials before we will compress the carousel script. The cheapest performance optimization is always the feature you decided not to build, and our contract reserves us the right to recommend that decision aggressively. Clients who hire us for a fast site do not get to override the constraint without renegotiating the budget upward, in writing.

Constraint two: twelve active plugins, hard cap

Every WordPress agency veteran has watched a site drift from a clean install to forty active plugins in eighteen months. Plugin count is a leading indicator of site health the way cholesterol is a leading indicator of cardiovascular health. It does not cause the problem on its own, but past a certain threshold the correlation becomes mechanical. Each plugin loads autoloaded options into the database. Each plugin enqueues scripts and styles into the front-end. Each plugin runs on admin-ajax calls. The combinatorics get ugly fast.

We cap active plugins at twelve. The number is not arbitrary, but it is also not magic. It is a forcing function. Twelve is enough to cover the genuine functional needs of almost any non-e-commerce WordPress site: a security plugin, a caching layer, an SEO plugin, a forms plugin, a backup tool, an SMTP handler, an analytics integration, a custom-fields tool, an image optimizer, and three application-specific plugins for whatever the site actually does for a living. Twelve covers the real needs and rejects the speculative ones.

When a stakeholder asks for plugin number thirteen, our contract gives us two options and only two. We retire an existing plugin, replacing its functionality either with code we add to the theme or with a feature already covered by another tool. Or we go back to the client and renegotiate the cap upward, which triggers a re-scoping conversation about what the site is actually for. We do not silently agree to thirteen plugins and then to fourteen and then to twenty-three. The cap is the contract.

The plugins we refuse on principle, regardless of the cap, deserve their own paragraph. We do not install page builders that ship the entire builder runtime to the front-end on every page. We do not install "all-in-one" plugins that bundle ten features when the client needs one. We do not install plugins whose authors have not pushed an update in eighteen months. We do not install plugins that score below 4 stars on the WordPress.org repository without a specific justification we can defend in writing. The plugin list is reviewed before development starts, signed off by both parties, and treated as part of the build specification.

Constraint three: 80 kilobytes of CSS per page template

CSS is the constraint most developers underestimate because it feels lightweight compared to JavaScript or images. It is not lightweight. It is render-blocking by default, it accumulates faster than any other asset on a WordPress site, and it is almost never audited in production. The HTTP Archive data on this is grim: a typical WordPress page ships roughly 75 kilobytes of CSS and uses less than a third of it. The rest is theme framework boilerplate loading every component's styles regardless of whether the page actually renders that component.

Our budget is 80 kilobytes of CSS per page template, measured after minification but before gzip, with a critical-path inline budget of 14 kilobytes, the size of a single TCP slow-start round trip, which is the practical ceiling for what can render the above-the-fold view in the first network round. Eighty total per template is generous compared to what a properly built block theme actually needs. Twenty Twenty-Four ships around 35 kilobytes. Bare Astra and Kadence builds land around 50 to 60. The 80-kilobyte ceiling gives us headroom for genuine custom design work without giving us license to drag in three icon fonts and an unused animation library.

The reason we budget per template rather than site-wide is that templates differ in legitimate ways. The homepage might earn its 80 kilobytes through real visual sophistication. A blog post template should not need more than 40. A landing page template might be 60. Per-template budgets force the conversation about which templates have earned visual complexity and which are coasting on the homepage's CSS bloat through global stylesheet inheritance. We measure each template independently. We do not let the homepage's heroics excuse the contact page's flab.

The fallback rule when CSS approaches the budget is conditional enqueueing first, removal second. If a block's styles only render on three pages, those styles should only enqueue on those three pages. WordPress 5.8 and later ship the wp_enqueue_block_style API specifically for this, and we use it aggressively. When conditional enqueueing has been done and the budget still cracks, the offending design element gets a second look. A custom font is the first thing that goes. A hover animation is the second. The constraint is not negotiable, but the implementation has dozens of sensible places to give before we capitulate.

What the manifesto does to the build process

The three constraints reshape every phase of how we build. During discovery, we ask clients to tell us which features are load-bearing for the business and which are decorative. We do this before design starts, because retroactive performance work after a maximalist design has been approved is the most expensive engineering on Earth. During design, we hand the designer the CSS budget as a working constraint, the same way a print designer works inside a fixed page size. During development, our staging environment runs a CI check on every pull request that fails the build if any of the three numbers exceeds budget. The check is enforced by code, not by goodwill, because goodwill on performance budgets evaporates the week before launch.

After launch, the budget continues. We monitor the LCP at the 75th percentile of real-user data through CrUX or a real-user monitoring tool, not synthetic Lighthouse runs in a clean environment. Synthetic scores tell you what could happen on a perfect device on a perfect network. Field data tells you what is happening to the actual users your site exists to serve. Those two numbers diverge. We pay attention to the second one. When the field data drifts, we have a documented procedure to investigate, attribute the regression to a specific change, and roll it back or refactor it.

What the manifesto does to the client relationship

A constraint published in advance is a gift to clients who have been burned by previous agencies. It tells them what they are buying with specificity unusual in this industry. It also tells them what they are not buying. We do not sell maximalist sites. We do not sell "everything the client asks for, on schedule." We sell sites that hit measurable performance targets and stay there, which sometimes means saying no to a feature request the client likes. The clients who want that arrangement self-select toward us. The clients who want a yes-shop go elsewhere, and both parties save themselves a painful project.

The manifesto also makes us legible to the developers and designers we hire. They understand the constraints before they take their first task. They can reason about whether their design will fit before they commit it to Figma. They can choose between three plugin candidates by checking which one fits inside the cap. The constraint produces predictable, defensible work, and predictable defensible work is what allows a small studio to ship at a quality level larger agencies cannot match.

Hire WitsCode for a build that defends these rules

If you are building a WordPress site and you want it to ship at 1.5 seconds LCP, run with twelve plugins or fewer, and stay under 80 kilobytes of CSS per template, that is the engagement we sell. We call it a constrained-budget WordPress build. The scope is fixed before development starts. The performance gates are written into the contract. The plugin list is signed off by both parties before the first commit. The CSS budget is enforced in continuous integration. We refuse to ship a site that fails any of the three constraints, and we put that refusal in writing.

If your current WordPress site is missing those marks and you want it brought into the budget, we run a separate engagement for that. It is shorter, more surgical, and almost always cheaper than a rebuild. Either way, the conversation starts with the three numbers. If those numbers describe the kind of site you want to own, we are the team to build it. Get in touch and we will send you a scoping questionnaire structured around the manifesto, with the specific decisions we need from you before we can quote the work. The constraints are the product. The site is what falls out the other side of the constraints.