Set a Performance Budget: How to Prevent Your Website from Becoming Slow Again
A performance budget turns speed into a concrete quality requirement. Here’s how to set limits for Core Web Vitals, images, code, caching and databases.
Category: Website performance
A website rarely becomes slow because of one major mistake. More often, many small changes accumulate: a new tracking tool, larger product images, an additional font, more content blocks and an extension that makes heavy database queries.
A single round of optimization therefore does not solve the problem permanently. The business also needs limits on how much each page can load the browser and server. That is what a performance budget does: It translates the desire for a fast website into measurable requirements that can be checked before publication.
A performance budget is more than a speed score
An overall score from a testing tool can be useful as a warning, but it does not necessarily explain what the user experiences. The score can also vary depending on the test environment, device and network.
A good performance budget therefore combines three types of requirements:
- User experience: How quickly the main content appears, how fast the page responds, and whether content shifts while loading.
- Technical load: The amount of images, JavaScript, CSS, fonts and third-party code that must be loaded.
- Server work: Response time, caching, database queries and the processing of dynamic requests.
The goal is not to make every figure as low as possible. The budget should protect the most important user tasks without preventing necessary functionality.
Create separate budgets for the most important page types
The homepage, an article page and a product page serve different purposes. They should therefore not be forced into exactly the same framework. Start with the page types that have the greatest impact on sales, enquiries or self-service.
A typical prioritization might be:
- Landing pages that receive paid or organic traffic.
- Product and category pages in the online store.
- Forms, checkout flows and other conversion pages.
- The homepage and key navigation pages.
- Articles and other supporting content.
For each page type, you should describe what needs to become visible first, which actions must respond quickly, and which elements can load later. This provides a better basis for decisions than one general requirement that “all pages must be fast.”
Use Core Web Vitals as outcome metrics
Core Web Vitals cover three key aspects of the user experience:
- Largest Contentful Paint, LCP: How quickly the largest visible content element is displayed. This is often a hero image, heading or large content block.
- Interaction to Next Paint, INP: How quickly the page provides visible feedback after clicks, taps and other actions.
- Cumulative Layout Shift, CLS: How much content shifts unexpectedly while the page is loading.
As an overall target, pages should normally have an LCP of no more than 2.5 seconds, an INP of no more than 200 milliseconds and a CLS of no more than 0.1. Measurements should be assessed for both mobile and desktop, and you should distinguish between laboratory tests and data from actual users.
Laboratory tests are well suited to development and pre-launch testing. User data shows whether the solution actually works across different devices, networks and geographical locations. A performance budget should use both: test data as a gatekeeper and user data for ongoing monitoring.
Set limits for the factors that affect the results
Images
Images are often the largest part of a page and a common cause of poor LCP. The budget should specify a maximum file size for the hero image and for the total amount of images loaded initially.
The requirements should also cover the correct image size for the display area, modern file formats and multiple variants for different screen widths. Images below the fold can load later, while the image that constitutes the LCP must be prioritized.
Avoid a rule that requires editors to remember every detail themselves. The publishing solution should automatically create appropriate sizes and prevent the upload of unnecessarily large files.
JavaScript and CSS
JavaScript can delay both rendering and responsiveness, especially on low-cost mobile phones. The budget should therefore limit how much JavaScript is loaded initially and how much work the code performs in the browser.
Assess each new feature based on the cost it adds for every visit. A chat, analytics tool or advanced menu may be useful, but should not be loaded on pages where the feature is not used. Split code by page type, remove unused code and defer anything that is not needed for the first interaction.
CSS should be treated in the same way. Critical styles for the initial viewport must be loaded early, while unnecessary stylesheets from extensions and components should be removed. Also be restrictive with fonts, font weights and icon sets.
Caching
Caching reduces the work that has to be repeated for each view. The budget should not merely require that caching «is enabled», but describe which layers should be used and how they are controlled.
- Browser cache: Images, fonts, CSS and JavaScript should be reusable between page views.
- Page cache: Completed pages can be delivered without the publishing system rebuilding them on every visit.
- Object cache: Results from repeated database operations can be stored temporarily.
- Caching close to the user: Static files can be delivered from a location with a shorter path to the visitor.
Dynamic pages require their own rules. Shopping carts, logins, stock status and personalized views cannot always be cached like ordinary content pages. Incorrect caching can cause serious functional errors, so exceptions must be documented and tested.
Database
A page can have small images and clean code, yet still be slow because the server is waiting for the database. This is often noticeable in searches, filtering, product lists and pages with many relationships between content types.
Do not use the number of database queries as the only metric. One poor query can be more costly than many simple ones. Instead, monitor total database time, slow queries, the amount of data retrieved and how often the same result is recalculated.
The database should also be cleaned of orphaned data, unnecessary revisions, expired temporary data and tables from extensions that are no longer used. This maintenance must be carried out in a controlled manner, with the ability to restore the data.
Include perceived speed in the budget
Technical measurements do not tell the whole story. A page may take a few seconds to complete all loading and still feel fast if the most important content appears first and the user receives immediate feedback.
Therefore, define requirements for the order of events:
- The heading, main message and primary action should appear early.
- Buttons should provide visible feedback as soon as they are activated.
- Space for images, advertisements and embeds should be reserved before the content loads.
- Heavy elements far down the page should wait until they approach the viewport.
- Waiting time in forms and searches should be explained with a clear status.
This reduces user uncertainty and helps prevent double-clicks, abandoned forms and navigation errors.
Make the budget part of the publishing process
A document alone will not prevent the website from becoming slower. The budget must be used whenever the design, content, code or third-party tools change.
- Measure the baseline: Record Core Web Vitals, page size, server response time and key resource volumes for selected pages.
- Set limits: Create separate requirements for each important page type and for mobile use.
- Test representative pages: Use realistic products, images, articles and data volumes. A nearly empty test page reveals little.
- Check before publishing: Stop changes that violate the budget, or require a documented assessment of benefit versus cost.
- Monitor after launch: Look for gradual changes and sudden deviations in data from real users.
- Assign responsibility: Clarify who is responsible for following up on images, code, hosting, the database and external services.
A simple exception form can be useful. If a new feature exceeds the limit, the team should describe why it is necessary, which pages are affected and what can be removed or loaded later to offset the cost.
A concrete starting budget must be adapted
You can start with a small set of requirements rather than measuring everything. An initial budget might, for example, include targets for LCP, INP and CLS, a maximum size for the main image, maximum amounts of initial JavaScript and CSS, requirements for server response time and a ban on new third-party scripts without an accountable owner.
The technical limits must be determined based on the current solution, users’ devices and business needs. A media-heavy inspiration site and a simple contact form need different budgets. What matters is that the limits are concrete, measurable and stricter than the level at which users begin to notice problems.
Speed becomes easier when it is treated as quality
Website performance should not be a cleanup job commissioned when someone complains. With a performance budget, editors, designers, developers and suppliers gain a common basis for decision-making.
The discussion then becomes more precise: not just whether a new feature can be built, but how much it costs in load time, responsiveness and server workload. This makes it possible to preserve a fast website even after numerous content changes and launches.
