With page speed becoming an important metric for both SEO and UX over the years, the concept of a web performance budget has also come to the forefront. It is now more evident that web performance is a topic that requires a shared perspective across all departments, rather than just being the priority of a single department or individual.
To explain this with an example: marketing departments might want to implement conversion and remarketing/retargeting codes, along with tools like Criteo and RTB House, which use product-based retargeting. They might also expect eye-catching photos and animations. Meanwhile, product departments may request the integration of tools like Hotjar and Clarity. Software departments, on the other hand, aim to develop as quickly as possible on both the frontend and backend. The demand and the costs associated with these demands on page speed are actually in balance. The web performance budget has emerged to establish this balance effectively.
A web performance budget involves setting a target speed for your platform on a specific platform and establishing numerical targets that all stakeholders will adhere to in order to achieve this speed. In short, the cost of being fast is the web performance budget.
Everything starts with a proposition. You propose how fast your page should open on a particular type of connection. For example, some performance budget propositions could be:
- Can the homepage open in under 2 seconds on a fast 3G mobile connection (1.6 Mbps)?
- Can the search results page open in under 5 seconds on a slow 3G connection (780 Kbps)?
Next, you create an action plan and sub-metrics to achieve these propositions, breaking it down into parts.
Aside from propositions, there can be other performance budget targets. For example:
- Increasing the mobile Lighthouse score of the detail page above 80
- Reducing the size of all images on the desktop site to below 500 KB
Performance Budget Metrics
There are three different perspectives accepted for determining the metrics of a performance budget:
Number-based metrics
- Maximum number of fonts / Maximum font size
- Maximum number of images / Maximum image size
- Maximum number of scripts, styles, videos, etc. / Maximum script, style, video, etc. size
- Maximum HTML size
- Maximum number of HTTP requests
- Maximum number of third-party scripts
Time-based metrics
- First Contentful Paint (FCP) time
- Largest Contentful Paint (LCP) time
- First Input Delay (FID) time
- Time to Interactive (TTI) time
- Total Blocking Time (TBT) time
- Cumulative Layout Shift (CLS) score
- Speed Index score
Rule-based metrics
- Lighthouse score
- GTmetrix score
- Webpagetest score
- Yslow score
When setting your web performance budget, it is generally recommended to combine all these perspectives in the right measure rather than choosing just one. You can use the performance budget simulator to find the numbers needed to reach your target speed.
Evaluate Page Types Separately
One crucial point when determining the performance budget is not to base it on a single page of the site. A common mistake is to test only the homepage, which leads to an incomplete evaluation.
You should start by examining the platform and identifying different types of pages. Then, analyze the platform's traffic to identify the pages that receive the most traffic and prioritize them. The result will be a table similar to this:
- Homepage
- Static listing pages
- Dynamic listing pages
- Detail pages
- Checkout pages
- Search results pages
- Campaign pages
- Blog pages
You need to focus on the performance budgets of these page types separately, based on the priorities.
