Performance budgets belong in planning

The homepage is fast on Monday. On Tuesday it gains a campaign video. On Wednesday analytics adds a tag. A personalisation test arrives on Thursday, followed by a new font weight on Friday.

Nobody made an obviously reckless decision. The page still became slow.

A performance budget exists to make the total cost visible before the browser sends the invoice to the user.

A budget is a product constraint

Web.dev makes the analogy directly: “Performance budgets work in the same way, but for metrics that affect website performance”.

The budget needs two layers:

• Experience limits describe what a user should feel: useful content appears promptly, interaction responds without a distracting pause and the page remains visually stable.
• Resource limits constrain the things a team can control before launch: critical JavaScript, image weight, font files and third-party execution.

Only measuring assets encourages teams to move work around. Only measuring field outcomes tells them about the regression after users have received it. Use both.

Budget the route, not the entire domain

A search-results route and a campaign story do different jobs. Start with the few templates that carry the most important journeys and answer these questions for each:

1. What must be visible before the page is useful?
2. What must be interactive before the user can continue?
3. What can wait until after interaction or remain opt-in?
4. Which devices and network conditions represent the audience?

Suppose a product-listing page currently ships 190 KB of compressed JavaScript. The team wants to keep 30 KB available for planned filtering work. The working budget becomes 220 KB, not because 220 is universal, but because the route has an explicit capacity and a known reason for it.

The same page might reserve a separate allowance for product imagery and require its largest above-the-fold image to be discoverable in the initial HTML. The numbers should be derived from the route and tested experience, then adjusted with field data.

Price third parties honestly

A third-party script consumes more than download bytes. It can occupy the main thread, add network connections, delay consent handling and fail outside the application's release process.

For each third party, record:

• the business owner;
• the routes where it is allowed;
• whether it blocks the primary task;
• what data it receives;
• the performance allowance it consumes;
• the event or date that triggers removal.

If a six-week campaign needs a 70 KB tag, that can be an explicit trade. If the tag remains two years later because nobody owns its removal, it has become architecture by neglect.

Put the decision in the pull request

Budgets work when a change meets them while it is still cheap to change direction. A useful pull-request check reports the difference, not only a red or green result:

/pricing
JavaScript: 208 KB → 231 KB  (+23 KB, budget 220 KB)
Largest image: 146 KB → 142 KB
Third-party main-thread time: +84 ms

The author can then remove weight, defer work or request an exception. An exception should name the benefit, approver and review date. Silent warnings teach teams that the budget is optional; unexplained hard failures teach them to distrust the tool. Context makes the gate useful.

Lab data is a rehearsal

Synthetic tests give repeatable conditions and fast feedback. Production data shows the range of devices, networks, content and account states the lab cannot reproduce.

The Core Web Vitals are designed around loading, responsiveness and visual stability, but an average across the whole site can still hide the slow route or device class that matters. Segment by template, release and meaningful platform characteristics. Watch the slower end of the distribution rather than celebrating a fast median.

When field data and lab data disagree, investigate the environment instead of choosing the friendlier chart. A consented user may receive more scripts. A cached visitor may hide a cold-load regression. A product page may contain customer-managed media that never appears in fixture data.

Spend speed deliberately

Performance budgets do not require plain websites. They allow a team to decide that a high-value interaction deserves more code while a decorative carousel does not. They give design, product, marketing and engineering one constraint to negotiate together.

That is how we approach web delivery, including high-traffic journeys such as Lloyds Mortgages: performance is part of the acceptance criteria, not a final polish pass.

The useful budget is not the strictest one. It is the one a team understands, enforces and revises using evidence.

Sources

• Your first performance budget — web.dev
• Web Vitals — web.dev
• Optimise Largest Contentful Paint — web.dev