WordPress Performance Budgets: Setting And Enforcing Them

WordPress sites that hit good performance can lose it gradually. Each new plugin adds weight; each theme update changes assets; each new feature has its own cost. Without explicit limits, the cumulative drift produces sites that were fast a year ago and aren't anymore.

Performance budgets are explicit limits: page weight, request count, third-party scripts, JavaScript size. The budgets become checkpoints that catch regression before it accumulates.

What budgets to set

Total page weight. The combined size of all resources for a typical page. Reasonable targets: under 1MB for content sites, under 2MB for marketing sites with imagery.

JavaScript size. The total JS transferred for a page. Reasonable targets: under 200KB for content sites, under 500KB for interactive sites.

Number of HTTP requests. Each request has its own overhead. Reasonable targets: under 60 requests for typical pages.

Third-party scripts. Each external script adds dependency and risk. Reasonable targets: under 10 third-party scripts per page.

Time to First Byte (TTFB). The time from request to first response byte. Target: under 200ms for cached pages, under 600ms for uncached.

Largest Contentful Paint. The Core Web Vitals metric. Target: under 2.5 seconds on mobile.

How to set realistic budgets

Measure current performance on representative pages. The current numbers are the starting point.

Set budgets at or slightly below current values. Don't set ambitious targets; set realistic ones that you can maintain.

Test the budgets against actual content. A budget that works for the homepage might be unrealistic for image-heavy gallery pages.

Adjust based on page type. Different page types have different reasonable budgets. Don't apply one budget to everything.

The enforcement mechanism

The budgets need enforcement to be useful. The mechanisms:

Manual quarterly review. Check representative pages against budgets. Identify regressions; investigate causes.

Automated monitoring. Tools like Lighthouse CI, SpeedCurve, or Calibre can monitor against budgets automatically. Alerts when budgets are exceeded.

Pre-deploy checks. Before launching new features, verify the changes don't exceed budgets. Reject changes that do.

The enforcement should match the team's operational maturity. Manual checks for small teams; automated monitoring for larger teams.

The plugin approval process

New plugins are the most common source of performance regression. The discipline:

Before installing any new plugin, measure performance baseline.

Install the plugin on staging. Measure performance.

If the plugin causes budget exceedance, evaluate: is the feature worth the performance cost?

If yes, install with awareness. If no, find an alternative.

The discipline prevents plugin sprawl. Each new plugin earns its weight by providing proportional value.

The third-party script governance

Third-party scripts (analytics, chat widgets, advertising, social media) accumulate quickly. Each addition seems small individually; the cumulative impact is large.

The governance pattern:

Periodic audit of all third-party scripts. Quarterly review.

For each script, evaluate: is it still needed? Is the value proportional to the cost?

Scripts that aren't producing value: remove them.

Scripts that are needed but heavy: see if lighter alternatives exist.

The audit usually identifies removable scripts. Sites that haven't audited often have 5-10 unused third-party scripts running.

The image governance

Images contribute the largest share of page weight on most sites. The image discipline:

Maximum file size policy. No image larger than X KB on a typical content page. The X depends on the page type but should be enforced.

Format requirements. WebP or AVIF as default; JPEG only when modern formats produce visual artifacts.

Dimension requirements. Images sized appropriately for their display context, not arbitrary high resolution.

Verification before publishing. The publishing workflow includes image size check.

Image optimization plugins handle some of this automatically. The discipline ensures the optimization actually happens.

The CSS budget

CSS accumulates over years. Plugins add CSS; themes have inherited CSS; custom styles get added. The cumulative size grows.

The audit: total CSS transferred for representative pages. Compare against budget.

If CSS is over budget, the actions:

Identify unused CSS via Chrome DevTools Coverage tab.

Remove unused CSS rules.

Combine related stylesheets to reduce request count.

Minify and compress.

The CSS work is moderate effort but produces consistent improvement.

The JavaScript budget

JavaScript is often the heaviest single category on builder pages and feature-rich sites. The budget:

Total JS under target.

JS execution time under target.

Third-party JS proportional to total.

If JS is over budget, the actions:

Identify unused JS via DevTools Coverage tab.

Defer non-critical scripts.

Remove plugin features that load JS but aren't used.

Evaluate lighter alternatives for heavy plugins.

The cache hit rate

For sites with caching, cache hit rate is part of the performance picture. A high cache hit rate means most visitors get fast cached responses; a low cache hit rate means many visitors pay full page generation cost.

Target: cache hit rate over 70% for typical content pages.

If cache hit rate is low, investigate:

Cache expiration too short. Pages expire before being re-hit.

Cache invalidation too aggressive. Content updates trigger cache purges that affect more pages than necessary.

Variable content. Pages with personalization or user-specific elements can't fully cache.

The mobile budget

Mobile has different reasonable budgets than desktop. The mobile network is slower; the CPU is slower; the screen is smaller.

Mobile budgets should be tighter than desktop. The user's tolerance is lower; the technical environment is more constrained.

Measure mobile specifically. The mobile PageSpeed score and CrUX field data are the mobile-specific metrics.

The reporting structure

The performance budget reports should be visible to the team responsible. The format:

Current state vs budget for each metric.

Trend over time. Are budgets being approached, met, exceeded?

Specific issues to address. Pages over budget; recent changes that caused regression.

Reviewed in regular team meetings. The visibility produces action.

The pattern that works

Teams that maintain performance over years use explicit budgets. The budgets:

Are set realistically based on current performance.

Are checked regularly (weekly or quarterly).

Are enforced through the deployment process.

Are adjusted as the site evolves.

Are visible to the team responsible.

The pattern produces sites that stay fast across years.

The pattern that fails

Teams that don't use budgets experience gradual performance decline. The decline:

Is invisible because nobody's measuring.

Accumulates from many small additions.

Becomes a major problem when finally noticed.

Requires large intervention to recover.

The "we'll watch performance" approach without explicit limits produces this pattern. The lack of triggers means regression accumulates without response.

The honest framing

Performance budgets are operational discipline. The setup is moderate effort; the maintenance is small ongoing effort.

For sites where performance matters (SEO-driven sites, conversion-driven sites, sites with mobile-heavy audiences), budgets are worth establishing.

For sites where performance is incidental, budgets may be over-investment. The simpler approach: quarterly review of PageSpeed scores.

The decision should match the strategic importance of performance. Don't over-engineer where it doesn't matter; don't under-engineer where it does.