The performance budget that keeps a new website from getting heavier
A website performance budget sets agreed limits and checks for the resources and behaviour that affect a page. Define it before adding features, test on representative devices and connections, and review it after changes. The budget should protect the useful experience, including working forms, rather than pursue a score alone.
Put the advice into practice
Give your next major prospect a clearer reason to choose you
Plan the content, design and enquiry pathways around the work you want to win.
Discuss your website projectBudget the experience as well as the downloads
A new website can become heavier one reasonable request at a time: another font, a larger hero image, a booking widget and an animation library. A performance budget gives the team a shared basis for discussing these additions before the final speed test.
Resource weight is only part of the picture. Two pages with similar downloads can behave differently depending on how resources are loaded and when the browser can render useful content. Google’s performance-budget guidance discusses both resource and experience measures.
Start with the important journeys and page types. A service page, article, portfolio gallery and booking screen may have different requirements. Establish a baseline for each and decide what the team needs to protect.
Write an illustrative budget with explicit assumptions
| Area | Illustrative team agreement | How to review it |
|---|---|---|
| Images | Choose responsive image sizes; review any single image above an agreed weight | Check the delivered image at real mobile and desktop widths |
| Fonts | Use two required weights initially; justify further files | Confirm actual text styles and fallback behaviour |
| Third-party scripts | Every new script needs an owner, purpose and loading decision | Review requests and test the interaction it supports |
| Page experience | Agree a repeatable mobile test and acceptable experience measures | Record the device, connection, tool and test conditions |
| Enquiry function | Forms, validation and confirmation must work after optimisation | Run a safe end-to-end test with a traceable test message |
The exact limits should follow the design, audience and baseline. A portfolio may need image detail that a text article does not. A useful budget makes that trade-off explicit, rather than assuming every page should have the same file count.
Assign responsibility for exceptions. If a feature exceeds an agreed limit, document why it is needed, what alternatives were considered and what will be retested.
Compare a feature with its full delivery cost
Imagine a hypothetical professional-services website considering an animated testimonial slider. The decision includes more than the size of the visible quotation. The implementation may introduce a script, styles, images and processing work, as well as a new interaction to test.
Compare that with a static selected quotation and a link to the full feedback page. If the static version communicates the same evidence and fits the design, it may be a useful alternative. If rotation serves a real purpose, test that implementation on the devices the organisation expects visitors to use.
This is a design decision, rather than a general ban on motion. The question is whether the value of the feature justifies its resource and interaction cost within the agreed experience.
Use repeatable tests and distinguish the evidence
Record the page, test conditions, tool and result. Lab tests provide controlled observations, while available field data reflects actual visits over a period. They are related sources of evidence but do not describe the same thing.
Repeat a test when the result is unstable or a material change has been made. Do not keep retesting only to select the highest score. Compare like-for-like conditions and investigate the resource or rendering issue behind a change.
Include a visual check. A faster result achieved by hiding important copy, breaking a menu or postponing a required form is not a successful release. Check layout stability, readable text, keyboard interaction and the route to the primary action.
Make the budget part of publishing and maintenance
Give content editors practical instructions for images, embedded video and new tools. A design can launch within its budget and drift later if those decisions are not part of the publishing workflow.
- Document the approved page types and resource approach.
- Identify which changes require a performance review.
- Keep a list of third-party tools and responsible owners.
- Retest important journeys after material updates.
- Review exceptions when the website or business requirements change.
Connect the budget to the website’s purpose. The goal is a responsive, dependable experience that lets a suitable visitor understand the offer and act. A score can help identify work, while the final judgement still needs the actual page and its functions.
Include a performance budget in your website design brief, along with essential integrations and enquiry functions. That gives the project a shared basis for assessing additions.
