Performance is easier to preserve when the team decides what the website is allowed to cost before implementation. A performance budget turns speed from a late optimisation request into a design and architecture constraint. It does not need to be perfect or universal. It needs to be measurable, connected to user journeys and strict enough to expose trade-offs.
Budget outcomes and causes separately
Outcome metrics describe what a user experiences: loading milestones, interaction delay and layout stability. Cause budgets describe what the system ships: requests, JavaScript, CSS, images, fonts, third-party work and server time. Outcome metrics can vary with devices and networks; cause budgets help the team understand what changed.
Suggested starting budgets
- Keep critical pages within an agreed Core Web Vitals range on representative mobile and desktop profiles.
- Set a maximum transfer size and request count for the initial viewport.
- Limit first-party JavaScript by page type, not only across the whole theme.
- Require intrinsic dimensions for meaningful images and reserve layout space.
- Load interactive block code only on pages that contain the block.
- Set a maximum number and cost for third-party origins.
- Define an admin response-time budget for the workflows staff use most.
Use page classes
A text article, service landing page, gallery and logged-in application should not share one arbitrary limit. Define a small set of page classes and assign budgets to each. The purpose is to make exceptions explicit. A video page can ship more media, but it should not silently become the baseline for every page.
Budget the administration area
WordPress performance projects frequently ignore the back office. Measure plugin settings, editorial screens, list tables and custom dashboards. Global admin bundles, unbounded queries and repeated remote requests can make the daily operating cost greater than the public-page cost.
Connect budgets to ownership
Every asset and request should have a feature owner. When a budget fails, the question becomes which capability changed and whether its value justifies the cost. Without ownership, performance work becomes anonymous cleanup.
Automate regression checks
A budget that lives only in a document will be forgotten. Add source-level asset limits, browser smoke tests and repeatable page measurements. Track the test environment and date. A single score is less useful than a stable method that reveals change.
Do not optimise the number instead of the product
Removing useful functionality to win a score is not performance engineering. The objective is to deliver the required experience with the least structural cost and to make deliberate exceptions visible.
For implementation and audit work, see WordPress Performance and Governance.