Set website performance budgets around the customer journey
Agree what must load and respond well, choose representative test conditions, and control the cost of images, scripts, and effects.
A performance budget turns “make it fast” into a set of decisions the team can review. Start with the pages and actions that matter to visitors, then agree acceptable loading and interaction behaviour under representative conditions. The budget should influence design and implementation while choices are still easy to change, rather than appearing only as a launch-day score.
Choose the journey and test conditions first
Identify the important routes: a first visit, a detailed service page, a work example, and the enquiry flow. Include both initial loading and movement between pages. An animated home page can appear smooth on a developer’s machine while a form becomes difficult to use on a less capable device.
Record the devices, connection assumptions, and page content used for comparison. Repeatable conditions make changes easier to assess. web.dev describes performance budgets as limits applied to performance-related measures and recommends combining different kinds of measures. Select measures that illuminate your actual journey rather than copying someone else’s thresholds without context.
Allocate the cost of the intended experience
List the images, fonts, scripts, video, and interactive scenes expected on each route. Decide which material is required for the first useful view and which can arrive later. A visitor should be able to understand the offer and reach navigation without waiting for every decorative asset in the site.
When a new visual effect or third-party widget is proposed, discuss what it adds and what it costs. The answer may be to simplify the effect, load it on a relevant route, or remove something less useful. A budget is valuable because it forces prioritisation, not because one particular file-size number guarantees a good experience.
Review regressions through behaviour as well as reports
Keep a record of the accepted baseline and compare meaningful changes against it. Investigate a regression in the context of the page: did the main image arrive later, did text move unexpectedly, or did a button stop responding promptly? A single score is a useful signal, but it does not explain every frustrating interaction.
Include content updates in the review process. Large replacement photography or a new embedded service can change the experience without altering the main application code. Give editors practical asset limits and a preview routine. Revisit the budget when the purpose of a page changes, documenting the reason rather than quietly allowing the limits to drift.
Practical checklist
- Choose representative pages, devices, and connection conditions.
- Record an accepted baseline for comparison.
- Separate first-view essentials from optional visual material.
- Review new widgets and media against their user value.
- Include editorial changes in performance checks.
Example: a 3D product page budget
A hypothetical product page presents its headline, specification summary, and enquiry link before the optional interactive model is ready. The team tests the basic journey with the model disabled and under slower loading conditions. A proposed extra scene is accepted only if the important reading and interaction experience remains within the agreed budget.
Common questions
Is a high audit score the whole goal?
No. Use reports to find and track issues, then inspect real tasks. The visitor experiences loading, reading, and interaction, not the score itself.
Should an existing website use the same budget as a new one?
Use its current purpose and constraints to set a realistic improvement plan. Record the baseline and prioritise the changes that most affect the important journey.
Further reading
Start with your actual workflow.
Turn the useful parts of this guide into a focused project brief.
Shape your project