The performance budget: How to stop your website from becoming slow again

Category: Website performance

Websites rarely become slow because of one dramatic error. More often, many small additions build up: a larger hero image, a new analytics tool, more fonts, an extension with its own stylesheets and a database that is never cleaned up. Each change seems harmless on its own, but users notice the combined effect.

A performance budget sets limits for how heavy a website or page type can be. It makes performance a specific requirement rather than a hope at launch. The budget can cover Core Web Vitals, image sizes, the amount of JavaScript and CSS, server response time and the number of external services.

The most important benefit is not a new measurement tool. It is that editors, designers, developers and suppliers get shared guidelines for the costs an amendment can impose on the website.

Start with the pages that matter most

There is little value in setting a single average target for the entire website. A simple contact page and a product page with filtering, video and stock status have different requirements. So start with a small selection of representative pages.

• The homepage, because it often contains large images, campaign sections and several components.
• An important service or product page, because it should guide the user towards taking action.
• An article or knowledge page, because such pages often receive significant traffic from search.
• A form, ordering flow or another page where slow performance can interrupt the customer journey.
• A search or category page, if the website has filtering and many database queries.

First, measure the current state. Use both controlled tests and real-user data where available. A lab test makes it easier to reproduce the same situation, while user data shows how the website performs on real phones, networks and in different locations.

Do not use the fastest test as the definitive answer. Test on mobile and with realistic limitations. The goal is to understand the experience of customers who are not using the same office, network and hardware as the developers.

Tie the budget to Core Web Vitals

Core Web Vitals provide three useful perspectives on user-perceived performance. They should be part of the budget, but not stand alone.

LCP: When does the main content become visible?

Largest Contentful Paint often concerns the largest visible element in the first part of the page. On many corporate websites, this is a hero image, banner area or large heading with a background image.

Poor LCP can be caused by an image that is too large, a font that loads too late, a slow server response or the browser discovering the main element too late. The budget should therefore not only state that LCP must be good. It should also set requirements for the maximum size of images in the first viewport and how quickly the server begins delivering the page.

INP: How quickly does the page respond?

Interaction to Next Paint measures how responsive the page is when the user clicks, taps or types. A page can appear complete but still feel slow if JavaScript keeps the browser busy.

This is particularly relevant for menus, filters, calculators, forms and consent solutions. The budget should set limits on how much JavaScript is loaded and require checks of heavy tasks running on the main thread. New tracking scripts and interactive components must be considered a cost, not just functionality.

CLS: Does the content stay in place?

Cumulative Layout Shift captures unexpected layout shifts. This could be a button moving just as the user is about to click it, or text jumping when a font, advertisement or consent box loads.

A good budget requires images and video areas to reserve the correct amount of space, dynamic elements to have predictable dimensions, and fonts not to cause major changes in the width and height of text.

Set limits the team can act on

A performance budget must be specific enough for someone to say yes, no or «only after optimisation». Choose a small number of metrics that suit your website and workflow.

• User experience: Requirements for LCP, INP and CLS for priority page types.
• Page weight: An upper limit for the total amount of data transferred on the initial load.
• Images: Separate limits for hero images, card images and other editorial images.
• JavaScript and CSS: The maximum amount of code that must be loaded before the page can be used.
• Server and database: Requirements for stable response times for both cached and uncached pages.
• External services: An approved list of analytics tools, chat, video, fonts and marketing scripts.

The limits must be based on current measurements, the organisation’s goals and the type of website you operate. An online store and a simple informational website do not need the same budget. Set requirements that are strict enough to influence decisions, but realistic enough to be used in practice.

Images must have an editorial cost

Image optimisation should be part of the publishing workflow, not a clean-up task every six months. Editors should be able to upload a good original image, while the publishing solution generates the right sizes and modern file formats.

The browser should receive an image sized for the space it will actually fill. A large image intended for a wide screen should not be sent unchanged to a small mobile device. Images further down the page can usually be loaded when the user approaches them, while the main image at the top must be prioritized.

Also be critical of the use of imagery itself. An image that does not explain, document or support the message should not consume part of the budget. Carousels with several large campaign images are a common example of high technical cost and unclear editorial value.

JavaScript and CSS must be justified function by function

A lot of JavaScript does not come from the website’s core functions, but from extensions and third-party services. Each new tool can load its own files, create network requests and perform work in the browser.

Before introducing a script, the owner should answer three questions: What specific task does it solve, which pages need it, and how do we measure its value? A chat tool may only need to load on sales and contact pages. A map does not need to start until the user opens the map section.

CSS should be treated in the same way. Remove rules that are not used, and avoid sending all component styles to every page. The most important content should be renderable without waiting for large stylesheets. At the same time, the optimization must be tested thoroughly so that it does not result in flickering content or components with the wrong appearance.

Caching does not hide a poor database

Caching can have a major impact because completed content can be delivered without the system rebuilding the page for every visit. This can apply to entire pages, database queries, images and other static files. Proper caching reduces work on the server and provides more consistent response times.

But caching must not become an excuse to overlook underlying problems. A page may be fast for anonymous visitors and very slow for logged-in users, editors or customers with items in their shopping carts. When the cache is cleared after an update, the weaknesses also become visible.

The database should therefore be examined separately. Look for heavy and repeated queries, unnecessarily stored revisions, orphaned data and extensions that load large amounts of data on every page. Scheduled jobs and integrations should not compete with visitors for capacity during busy periods either.

Measure perceived speed, not just load time

Users are waiting to understand and take action, not for a measurement tool to declare the page finished. Perceived speed can therefore be improved even when the total amount of data does not change dramatically.

Show the most important content first. Provide immediate feedback when a form is submitted or a filter is activated. Use simple loading states when processing takes time, and avoid empty spaces that suddenly fill up. Also ensure that buttons work when they look clickable.

A page that quickly displays the heading, price, main message and next action feels better than a page where decorative elements block the content. This is a collaboration between design, content and development.

Make the budget a gate before publishing

The performance budget only works when it influences changes. Therefore, add a simple check to the workflow for new templates, campaigns, extensions and external services.

1. Measure the relevant page type before making the change.
2. Test the change in a separate environment with realistic content.
3. Compare Core Web Vitals, page weight, script volume and server response.
4. Investigate deviations on mobile, not just on a fast work computer.
5. Optimize, remove something else or document why the budget is temporarily exceeded.
6. Measure again after publishing to identify differences in production.

Also assign responsibility. The editor can own image use, marketing can own third-party scripts, the developer can own code and the database, while a web manager follows up on the whole picture. Without clear ownership, every small addition gets approved while no one is responsible for the total.

A budget makes the priorities visible

The point is not to make the website as technically small as possible. The point is to use capacity on what creates value for the customer and the business. A useful product selector may be worth the technical cost. An automatic background video that few people watch is harder to justify.

When the budget is exceeded, the team must choose: optimize the function, limit where it loads, remove something else or accept a documented cost. This makes performance part of the product decision. That is how a fast website stays fast after the launch project is over.