Set a performance budget before the website becomes slow
A performance budget makes speed a concrete requirement for images, code, caching and databases—not a cleanup project before launch.
Category: Website performance
A website rarely becomes slow because of one dramatic error. Often, the cause is the combined effect of a large hero image, several tracking scripts, a heavy font, inefficient caching and database queries that grow with the amount of content. Each decision may seem reasonable on its own, but together they result in long wait times and a page that responds slowly.
A performance budget sets limits before this happens. The budget describes how quickly the website should feel, and how much image, JavaScript, CSS, third-party code and server processing a page type may use. This gives designers, developers, editors and suppliers a common basis for decisions.
Start with business-critical pages
There is little value in creating one overall speed requirement for the entire website. A simple contact page, a product page and a logged-in customer page have different purposes and technical prerequisites.
First, choose a few representative page types and user tasks:
- home page or important landing page
- service or product page
- article or guide
- search, filtering or product listing
- form, order or checkout
Prioritize pages that receive a lot of traffic, start a customer journey or are closely tied to a conversion. Also measure important steps within the page. A product page may load quickly but still feel slow if selecting a variant or opening the shopping cart responds slowly.
Use Core Web Vitals as outcome requirements
Core Web Vitals provide three useful measures of the user experience. They should be included in the budget, but should not stand alone.
- Largest Contentful Paint, LCP: How quickly the most important visible content is displayed. A practical target is 2.5 seconds or less.
- Interaction to Next Paint, INP: How quickly the page provides visible feedback after clicks, taps and keyboard input. A practical target is 200 milliseconds or less.
- Cumulative Layout Shift, CLS: How much content shifts unexpectedly while the page is loading. A practical target is 0.1 or less.
Assess the targets at the 75th percentile, especially for mobile traffic. This means the requirement should be met for a clear majority of visits, not just on the developer's fast machine and network.
Measurements in a testing tool are useful during development. Data from actual visits shows how the website performs on real devices and networks, with real consent choices and content. The budget should therefore specify both pre-launch testing requirements and follow-up with real users afterward.
Turn outcome requirements into technical limits
Core Web Vitals indicate that something is slow, but not always why. The budget must therefore include limits that the team can use in day-to-day work.
Images: set budgets by placement
Do not use one maximum file size for all images. A wide hero image has different requirements from a small profile image. Instead, define requirements for each image placement:
- maximum display dimensions on mobile and large screens
- suitable file formats and compression levels
- multiple image sizes so mobile devices do not load the desktop version
- fixed width-to-height ratios to prevent layout shifts
- rules for which images can be loaded later
The image likely to become the page's LCP element should normally not be lazy-loaded. It must be detected and fetched early. Images further down the page can be loaded when the user approaches them.
It is a good idea to set a specific file-size limit for each template after testing real images. A detailed product photo does not necessarily tolerate the same compression as a simple illustration. The goal is low file size without visible quality loss at the size the image is actually displayed.
JavaScript: budget execution, not just kilobytes
A small JavaScript file can be costly if it performs a lot of work in the browser. A larger file may be less problematic if it is loaded when needed and does little on the main thread. The budget should therefore cover both the amount of data transferred and the time the code takes to execute.
Distinguish between code required for the initial display, code that can be loaded afterward and code needed only on certain page types. A map, calculator or product configurator should not be included on every page if the feature is used in only one place.
Third-party scripts must be treated as part of the budget. Analytics, advertising, chat, video and personalization compete for the same resources. Each script should have a named owner, a clear purpose and a removal plan if it no longer provides value.
CSS and fonts: prioritize what is visible first
Large stylesheets can delay rendering, even when much of the content applies to components that are not present on the page. Remove unused rules, split the code where appropriate and prioritize the styles needed for the initially visible area.
Fonts affect both load time and layout stability. Limit the number of font families, styles and weights. Use fallback fonts with similar proportions so that text and buttons do not shift significantly when the web font becomes available.
Caching: specify what can be reused
A good caching setup prevents the server and browser from doing the same work again. The budget should not merely require “caching”, but describe what should be cached and when the content should be refreshed.
- Images, fonts, CSS and JavaScript can often be stored for a long time when the filename changes with new versions.
- Generated pages can be cached when the content is the same for many visitors.
- Personalized pages, shopping carts, and logged-in content require separate rules.
- Database queries or calculated results can be cached when the data does not need to be completely up to date.
Always test that publishing, prices, stock status, and personal data are updated correctly. Aggressive caching without clear rules can produce fast but inaccurate pages.
Database: set limits before content grows
A solution can be fast with ten products and slow with ten thousand. The database budget should therefore be tested with realistic data volumes, not just an almost empty development database.
Monitor the server’s response time, the number of queries, and the slowest queries for important page types. Search, filtering, and sorting deserve particular attention. Avoid solutions where every new product, filter, or content element leads to an increasing number of separate lookups.
Cleanup is also part of the work. Unused data, old revisions, expired caches, and tables left behind by removed extensions can make maintenance and troubleshooting more difficult. This cleanup must be planned and backed up, not performed at random in production.
Include perceived speed in the budget
A page can achieve good technical metrics and still feel slow. Users need to understand that something is happening, what is available, and when they can continue.
Therefore, define some requirements for perceived speed:
- Display the page heading and most important content early.
- Provide immediate visual feedback when a button is activated.
- Keep existing content visible while new search results are being retrieved.
- Reserve space for images, notifications, and dynamic components.
- Avoid loading screens that hide content that could already be used.
A button that changes its text to “Adding” feels better than one that appears unresponsive for a second. This type of feedback does not necessarily make the server faster, but it reduces uncertainty.
Make the budget part of the approval process
A document alone will not keep a website fast. The requirements must be checked when the design, features, and content are approved.
- At the outset: Choose page types, user tasks, measurement conditions, and Core Web Vitals targets.
- During the design phase: Consider the impact of large media areas, fonts, animations, and components.
- During development: Monitor the size and runtime of images, code, and third-party functionality.
- Before launch: Test with realistic content, less powerful mobile devices, and a cold cache.
- After launch: Monitor real-user data and investigate changes by page type and device.
Also agree on what happens when limits are exceeded. The team can optimize the feature, load it later, limit it to relevant pages, or remove something else. If every request is treated as an addition without any corresponding trade-off, the budget is merely a wish list.
A small budget is better than an extensive document no one uses
Start with a few requirements that can be measured and assigned to responsible parties. Core Web Vitals describe the outcome. Limits for images, JavaScript, CSS, caching, and the database make that outcome possible to control. Requirements for perceived speed ensure that you do not optimize only for a score.
The most important effect is not that every page becomes technically perfect. It is that performance is considered alongside design, functionality, and content. That way, you avoid discovering just before launch that the website needs to be rebuilt to become fast enough.
