Performance Budgets Across a Client Site Portfolio

One client site is fast. The other nineteen are somewhere between fine and embarrassing, and you only find out which is which when a client forwards a PageSpeed screenshot. Performance work at portfolio scale is not a series of rescues — it is a standard you set once and then measure against.

A WordPress performance budget is that standard: a small set of numbers a site is not allowed to exceed, checked automatically, with a named consequence when it fails. This post covers what to put in the budget, how to set thresholds per site tier, how to monitor twenty or more sites without hiring anyone, and how to sell the whole thing to clients as part of a retainer rather than as a favour.

Why one-off speed fixes never hold

You optimise a site in March. By September it has a new hero video, a chat widget, two analytics scripts the client’s media agency added, and a plugin that loads jQuery UI on every page. Nothing was reckless. Performance simply has no owner and no ceiling, so it drifts downward like any unmeasured quantity.

The budget fixes this by turning speed from an opinion into a pass or fail. When a request comes in to add a third tracking script, the conversation stops being aesthetic — “will this slow us down?” — and becomes arithmetic: the page has 180KB of JavaScript headroom, the script is 240KB, so something has to give. That is a far easier conversation to have with a client than a lecture about Core Web Vitals.

What goes in a WordPress performance budget

Keep it short. A budget nobody can remember is a budget nobody enforces. Four to six metrics is the practical limit, split between what users experience and what causes it.

Metric	Type	Typical budget	Why it earns its place
Largest Contentful Paint	Experience	Under 2.5s on mobile field data	The number Google reports and clients quote back at you
Interaction to Next Paint	Experience	Under 200ms	Catches heavy third-party and builder JavaScript
Cumulative Layout Shift	Experience	Under 0.1	Usually cheap to fix, embarrassing to leave
Total JavaScript transferred	Cause	Under 300KB compressed	The single best predictor of INP problems
Total page weight	Cause	Under 1.5MB on a template page	Simple, understandable, easy to trend
HTTP requests on first load	Cause	Under 60	Surfaces plugin sprawl faster than anything else

Cause metrics matter more than experience metrics for day-to-day work, because they are deterministic. Lab LCP moves around with network conditions; the byte weight of your JavaScript bundle does not. Track both, but enforce on the causes.

Set thresholds by site tier, not by ambition

A twelve-page brochure site and a 4,000-SKU WooCommerce store cannot share a budget. Sort the portfolio into three tiers and give each one its own numbers.

• Tier 1 — marketing and landing pages. Tightest budget. No excuse for more than 150KB of JavaScript. These pages carry ad spend, so speed maps directly to money, which is why we treat this as a build standard rather than as a later optimisation pass.
• Tier 2 — content sites and blogs. Moderate budget. Images and embeds are the main risk; third-party scripts are the second.
• Tier 3 — WooCommerce and membership. Loosest budget, tightest monitoring. Cart and checkout are uncacheable, so measure server response time separately and watch it weekly.

Write the tier into the client record next to the hosting details. When someone on your team picks up a ticket, the applicable budget should be one click away, not a matter of memory.

Establishing the baseline across the portfolio

Do not start by fixing anything. Start by measuring everything, once, in a consistent way.

1. Pick three URLs per site. Homepage, the highest-traffic template page, and the highest-value conversion page. Three is enough; twenty is a project nobody finishes.
2. Run a scripted lab test. Lighthouse CI or WebPageTest via API, mobile emulation, same throttling settings for every site. Store the JSON output.
3. Pull field data where it exists. The Chrome UX Report API gives you real-user LCP, INP and CLS for sites with enough traffic. Field data wins any argument with lab data.
4. Record the causes, not just the scores. Bytes by resource type, request count, server response time, and the top three render-blocking resources.
5. Sort by gap, not by score. The site to fix first is the one furthest above its own tier budget, which is often not the one with the worst absolute number.

Budget one to two hours per site for the baseline pass including the write-up. Across twenty sites that is a week of work, which comfortably fits inside a mid-tier monthly retainer if you spread it across a quarter.

Monitoring twenty sites without adding headcount

Manual checks stop happening by week three. Automate the measurement and keep humans for the judgement calls.

• Weekly scheduled runs. A cron job hitting the PageSpeed Insights API for every tracked URL costs nothing and produces a trend line. Trends catch slow decay; single tests do not.
• Alert on the delta, not the absolute. A site that goes from 1.9s to 2.4s LCP is still “green” and is still the thing you want to know about this week.
• One dashboard, all sites. A spreadsheet with conditional formatting is genuinely fine. The requirement is that anyone on the team can see every site’s status in ten seconds.
• Tie alerts to deploys. If a budget breach lands the same day as a plugin update, you already know the cause. This is much easier when releases go through a controlled staging to production deployment workflow.
• Review monthly, act quarterly. Unless something breaches badly, batch the remediation work so it is efficient rather than reactive.

For agencies without the internal capacity to run this, monitoring is one of the easiest things to hand to a partner, because the output is objective. It sits naturally inside WordPress maintenance and support alongside updates and backups, and the deeper remediation work under WordPress speed optimization.

What to do when a site breaches its budget

Have a fixed response, so the decision is not relitigated every time. A workable escalation looks like this:

1. Under 10% over budget. Log it. Fix it in the next scheduled maintenance window.
2. 10–25% over. Open a ticket this week. Nine times out of ten the cause is an unoptimised image, a new third-party tag, or a plugin loading assets site-wide.
3. Over 25%, or a Core Web Vitals metric moving from green to amber. Treat it as an incident. Identify the change that caused it and roll it back or isolate it before optimising anything else.

Most breaches resolve with unglamorous work: correctly sized and lazily loaded images, deferring scripts that do not affect first render, removing a plugin whose one feature could be twenty lines of code, and putting object caching in front of a database that has quietly accumulated 40,000 rows of expired transients. For a first-response sequence on a single site, our seven-step Core Web Vitals rescue is the shorter version of this playbook.

Selling the budget to clients

Do not sell it as performance. Sell it as protection of something the client already cares about: ad spend efficiency, search visibility, or checkout completion. Then make the budget a clause rather than a promise.

Three sentences in the retainer scope are usually enough. State the metrics, state the monitoring frequency, and state that changes requested outside the budget will be quoted with their performance cost attached. That last clause is what stops the site degrading, and it also protects your margin when the client’s other suppliers start adding scripts. Structuring that into a priced package is covered in our post on WordPress maintenance retainers for agencies.

Frequently asked questions

What should a WordPress performance budget actually contain?

Two or three user-experience metrics — LCP, INP and CLS — plus two or three cause metrics such as total JavaScript weight, page weight and request count. Anything beyond six numbers stops being used. Set the numbers per site tier and record them where the delivery team can see them.

Lab data or field data?

Both, for different jobs. Field data from the Chrome UX Report tells you what real users experience and is what search engines use. Lab data is repeatable, available immediately on low-traffic sites, and is what you test against before a deploy.

How much time does this take per month?

After the baseline, roughly 30–60 minutes per site per month for review plus whatever remediation the trend demands. Across twenty sites that is a predictable block of hours, which is why it fits an hour-based retainer rather than ad-hoc billing.

Does a page builder make budgets impossible?

No, but it raises the floor. Builder sites carry more CSS and JavaScript by default, so set their thresholds honestly rather than pretending a Divi site will match a hand-built theme. Disabling unused builder modules and global assets recovers a surprising amount.

Can this be outsourced without losing control?

Yes, because everything in a budget is measurable and reportable. You keep the client relationship and the thresholds; a partner runs the monitoring and remediation under your brand. The wider model is set out in our guide to white label WordPress development for agencies.

Next step

Pick three URLs on your five most valuable client sites, measure them this week, and write down the numbers you are not willing to exceed. That is a performance budget. Everything else is process around it.

If you would like the baseline pass and ongoing monitoring handled for you, our dedicated monthly plans cover portfolio work of this kind under NDA, in your PM tool, with no lock-in.