Stop Your Website Before It Gets Slow: Introduce a Performance Budget for Each Page Type
A performance budget turns speed into a concrete requirement for development and publishing. Here’s how to set limits for images, code, server processing and Core Web Vitals.
Category: Website performance
Websites rarely become slow because of one major error. It usually happens gradually: a new tracking tool, larger images, another font, a heavier content block and more database queries. Each change seems reasonable on its own, but together they result in poorer performance.
A performance budget sets limits before this becomes a problem. The budget describes how much a page type can load the browser, server and user. For example, it can specify the maximum image size, amount of JavaScript, server response time and acceptable Core Web Vitals values.
The goal is not to make every page extremely lightweight. It is to prioritise deliberately and detect deterioration before it reaches production.
Create a budget for each page type, not the entire website
A homepage, product page and article page have different purposes. One shared requirement for the entire website will therefore be either too strict or too lenient. Instead, create a small set of budgets for the page types that matter most to the organisation.
An online store could start with these:
- Home page
- Category page
- Product page
- Cart and checkout
- Article or guide
For a service website, service pages, a contact page and landing pages may be more important. Choose representative pages with real content. An empty test page says little about how the page template works once the editorial team has added images, forms and related articles.
Combine user experience and technical limits
A good performance budget does not need to consist of many metrics. It should cover the most important parts of delivery and be simple enough to use in practice.
Core Web Vitals
Core Web Vitals describe key parts of the user experience: how quickly the main content appears, how stable the layout is and how quickly the page responds when the user does something.
Pay particular attention to:
- Largest Contentful Paint: When the largest visible content element, often a hero image or headline section, is displayed.
- Interaction to Next Paint: How quickly the page provides visual feedback after a click, tap or keyboard input.
- Cumulative Layout Shift: How much content shifts unexpectedly while the page is loading.
Use the recommended thresholds as a starting point, but also measure your own critical actions. On a product page, this could be the time from when the user selects a variant until the price and availability are updated. In the checkout, it could be the response after the customer selects a delivery method.
Page weight and number of requests
Supplement user-oriented metrics with limits for what the page downloads. These can include the maximum total transfer size, amount of image data, JavaScript and CSS. The number of network requests can also be useful, especially when the page loads resources from many external services.
These limits do not explain the entire user experience, but they make the causes easier to identify. If the JavaScript budget is exceeded after a new analytics tool is added, the team knows where to begin its investigation.
Server and database
The front end can be well optimised and still spend a long time waiting for the server. Therefore, set a requirement for how quickly the server should begin delivering content, both with a warm cache and without a cache.
Measuring without a cache is important on pages that are personalised, frequently changed or cannot be fully cached. Here, database operations, integrations and calculations can be the real bottleneck.
Allocate the budget to the most important costs
When a page type exceeds its budget, the team must be able to determine who or what used the space. Therefore, divide the budget into a few practical categories.
Images
Images are often the largest amount of data on content-heavy pages. Requirements should cover more than file format. Also specify the correct dimensions, compression and which images should load first.
The hero image should be sized for the space it actually occupies. Less important images further down the page can load as they approach the viewport. The browser should be told the image’s width and height in advance, so the content does not jump while the file loads.
Create fixed image variants in the publishing solution. Editors should not have to calculate the correct pixel dimensions or file sizes every time. Performance becomes more robust when good choices are built into the workflow.
JavaScript and CSS
JavaScript costs both download time and processing power. A small file can still cause problems if it occupies the browser for a long time. Therefore, consider whether the feature needs to be available immediately, can load later or can be implemented without extensive scripting.
Split code according to need, and avoid sending every page features that are only used in one place. An article page normally does not need code for product filtering, maps or advanced forms if those features are not present there.
CSS should follow the same principle. Prioritise the styles needed for the initial view, and remove rules that are no longer used. At the same time, make sure the optimisation does not create a brief flash of unstyled or incorrectly positioned content.
External services
Consent solutions, analytics, advertising, chat, video and personalisation can make up a significant part of the load. These services must be included in the budget, even if the code is provided by a third party.
Ask each service to justify its cost. Does the chat need to load before the user has shown interest in making contact? Do all marketing scripts need to run on the confirmation page? Can the video be shown with a lightweight preview image until the user chooses to play it?
Database work
The database budget may include requirements for query time, the number of expensive queries, and total processing time for key page types. Pay particular attention to search, filtering, related products, and dynamic content blocks that do a lot of work for each view.
Caching can reduce the load, but should not hide inefficient queries. When the cache expires or is cleared, the cost returns. Therefore, optimize the underlying work before increasing the cache duration.
Test both cache hits and cache misses
Caching has a major effect when the same content is requested multiple times. This can happen in the browser, close to the user, on the web server, or in the application. A performance budget should describe the expected result both when content is available in the cache and when the system has to build the response again.
If you only test pages with warm caches, the results may look stable until a publication, deployment, or increase in traffic clears parts of the cache. Therefore, test the following situations:
- First visit from a new user
- Repeat visit with resources in the browser cache
- Page view after the server cache has been cleared
- Logged-in user or shopping cart with personalized content
- Page view while an external integration is responding slowly
This reveals whether performance is due to good architecture or merely favorable test conditions.
Include perceived speed in the assessment
A page can stay within the technical budget and still feel unclear or slow. Users need early confirmation that the page is working.
Therefore, show important content first. Reserve space for images and dynamic elements. Provide immediate visual feedback on buttons, and use clear loading states when an operation actually takes time. Do not block the entire page if only one content section is being updated.
On a filterable product page, the selection can be highlighted immediately while the results list indicates that it is being updated. In a form, the button should change state after submission so that the user does not click it multiple times. Such measures reduce uncertainty without pretending that processing is complete.
Make the budget part of the delivery process
A spreadsheet that is checked once a year will not prevent performance degradation. The budget must be used when the team develops, publishes, and purchases new services.
- Establish a baseline: Measure representative pages with realistic content on mobile and desktop.
- Set limits: Choose a few requirements for Core Web Vitals, images, code, server response, and the database.
- Test before launch: Compare new versions with the baseline before publishing changes.
- Alert on degradation: A minor deviation can trigger an alert, while a serious deviation should stop the rollout.
- Track real users: Laboratory tests are repeatable, but must be supplemented with data from actual visits and devices.
- Assign responsibility: Clarify who evaluates deviations and who can approve a larger budget.
Do not require every overrun to be resolved by removing the feature. Some features are worth the cost. In that case, the decision should be explicit: What business value does the feature provide, where is the impact felt, and what can be simplified elsewhere?
Start with one specific budget
Begin with the page type that has the greatest impact on sales, inquiries, or self-service. Measure the current situation, identify the greatest cost, and set limits that are ambitious but realistic.
A performance budget works best as an agreement between design, development, content, and marketing. It makes the consequences of new choices visible. When someone wants a larger video, a new tracking tool, or a more advanced component, the team can assess the benefits against a known budget instead of discovering the slowdown after launch.
