Since I was in my teens I’ve been interested in both sustainability and design. When I co-founded Wholegrain Digital with Vineeta over a decade ago, it was natural that I wanted the business to embody my interests and values. Over the years we’ve built a team who care about good design and sustainability, and it’s led to us being a bit obsessed with efficiency. So much so that we refer to our design and development process as efficiency by design. In essence, our objective is to create solutions that do the most with the least.
Efficiency by design means is figuring out how to achieve the client’s goals with the least amount of data.
The best results are achieved when efficiency is prioritised from the beginning of a project, not as an afterthought. One of the best ways to achieve high levels of efficiency is to agree a page weight budget and use it as a metric of project success.
We learned about page weight budgets from Tim Frick over at Mightybytes in Chicago and it has been transformative in pushing our work to the next level. When we integrate page weight budgeting into our projects, we create websites that are significantly faster, deliver better user experience, perform better in search engines and are more sustainable.
This post is about creating your own Page Weight Budgets, how you can use them in real projects to deliver better user experience, and how they can ensure you do your part in the face of the Climate Emergency.
What is a page weight budget?
A page weight budget is literally a budget of how much a webpage can weigh. Not in grams of course, but in kilobytes or megabytes of files. Specifically, it is the size of files transferred over the internet when a webpage is loaded.
When the budget has been set, the team’s goal is to deliver each key page of the website in no more than the agreed budget, ideally less. It is a clear benchmark for all members of the team to focus on in planning and design through to development.
It’s just like a project budget, but for your pages.
How to set a page weight budget
The purpose for a page weight budget is to focus the project team on making the website as efficient as possible, but the budget does have to be realistic.
When we first started using page weight budgets, our developer, Jerome, asked me what the budget should be in an ideal world, to which I replied “zero kilobytes”. In reality we can’t be so idealistic; we can’t deliver websites without transferring any data. So, we need to be realistic about what’s feasible.
Our page weight budgeting process aims to be both realistic and ambitious, by following these three simple steps:
- Benchmark! Benchmark the old version of the same website and also the main competitors to identify what is typical in the industry. Aim to be at least 20% more efficient than the best in the business.
- Worst connection! Identify the worst likely connection of your target users and their expectation of load times. Calculate the budget from that. A tool such as http://www.performancebudget.io/ can be used to estimate this.
- Decision! Use your experience and gut instinct to agree a budget from these two numbers. It might be a range, with point 1 being the minimum standard and point 2 being the stretch goal.
The above process is not inherently complicated and anyone in the team could follow these steps and propose a budget. What’s more important is that somebody takes ownership of the budget from start to finish, and seeing as the Project Manager is accountable for the overall success of the project including its financial budget, it makes sense that they take the lead on the page weight budget too.
They need to take into account the practical needs of the client, the websites target users and any known technical constraints that are defined in the project brief. For example, if you know that the website must have Intercom live chat integrated, then you should set the budget to allow for that.
I know, you want to see an example
I thought it would be helpful to illustrate this with a real example of a project where we’d used this process.
The Sustainable Web Manifesto website is designed to be a living example of green web design. Therefore, when we created it we had to push for high levels of efficiency while ensuring that it looks fantastic. This is how we went about setting the page weight budget.
- Benchmark: There was no old version of this website and no direct competitors, so we looked at the best known manifesto website in our industry, which is the Agile Manifesto. This has a page size of 70.4kb. A 20% improvement would therefore be 56kb.
- Worst connection: The worst likely connection speed for visitors of the Sustainable Web Manifesto is probably 2G, as this is still surprisingly common even in the UK in places such as trains. As we want to sell the benefits of a greener web in terms of performance, ideally it would load within 3 seconds on 2G. According to Performance Budget this gives us a target budget of 13.1kb
- Decision: From the above, it seems reasonable that the website should have a page size somewhere between 56kb and 13kb. The most efficient website developed by our team at Wholegrain Digital is Website Carbon with a page size of 28kb. We therefore know that this is possible and so we set the budget as 28kb and the stretch goal as 13kb.
The final homepage of the Sustainable Web Manifesto came out at 30.6kb. Yes, we missed the budget by a couple of kilobytes, but having the budget in place meant that we delivered an incredibly efficient product. It can be harder to work to such a small budget on client projects, but using a page weight budget still pushes the team to deliver high levels of efficiency. Another example is fellow B Corp Red-Inc, whose website we aimed to be the most efficient client website we had ever created. It was delivered in 278kb, a fraction of the size of Red-Inc’s competitors websites and a lot faster as a result.
What are the benefits?
Like anything in life, setting a tangible goal focuses the mind. By setting a page weight budget, you’re likely to deliver a far more efficient website, even if you fail to hit your target.
Since we introduced page weight budgeting into our process we have seen the following benefits:
- Average page sizes reduced dramatically
- Improved user experience
- Improved accessibility
- Reduced carbon emissions
Not bad! I’m sure you’re now asking: “is it really that easy?”
Is it really that easy?
Yes and no.
Setting a page weight budget really is incredibly easy. The real challenge is getting key stakeholders to buy into it. It’s easy on our own websites, but much harder with client websites. The best approach for getting clients on board with a page weight budget is to show them what it means in terms of the things that they care about, whether that’s load time for mobile users, the environmental impact, or the cost to visit the site for a user in a developing country.
Efficient websites benefit all users, but it’s helpful to demonstrate to the client how it will benefit their own target audience.
The next challenge is agreeing what the budget should be. As it can be hard for clients to visualise the implications of a very tight budget, they understandably tend to be cautious and don’t want to limit themselves by setting the budget too low. That’s fair enough and that’s why we suggest setting a budget range with a realistic upper limit and a more ambitious stretch goal. It allows everyone to strive to do better without feeling like they’ve over committed themselves to a puritan approach that may prevent them from achieving other goals.
So, we’ve set a budget that everyone is comfortable with. The next challenge is sticking to it.
There’s really no benefit in setting the budget if you don’t look at it again until the website is launched. It needs to be integrated into every step of the project, and led by the Project Manager, whose job it is to ensure that the project achieves all of its agreed goals. It means asking tough questions, like, “Is that stock photo of a boardroom meeting really adding any value?” and constantly estimating progress against the budget by checking approximate sizes of image files, fonts, code libraries, etc.
Above all, it’s about constantly asking could we achieve an experience just as good with even smaller files? And if so, how? It also means telling the team the reality when a decision will result in missing the budget. Everyone on the project team needs to be aware of the decisions that they’re making, and why they committed to the budget in the first place.
Handy reference tables
It’s helpful to have some example file sizes to refer to when designing a website to a page weight budget. Here are some useful examples.
Fonts
Fonts are arguably the stealthiest contributor to the weight of a web page. Most people don’t think about the size of font files on the web but they can have a huge impact if we’re not careful. The table below gives a few examples, highlighting how system fonts can be used with no impact on page weight at all, and how custom fonts can have multiple large files covering different weights such as regular, bold and italic. The table also highlights how the size of the font files is impacted massively by the file format used and whether you use the full character set or only a subset of the font with the required characters (e.g. English characters only).
Fonts | System Font | TTF | WOFF2 | Subset WOFF2 |
Arial | 0kb | |||
Times New Roman | 0kb | |||
Inter UI Regular | 253kb | 88kb | 10kb | |
Inter UI Bold | 256kb | 95kb | 10kb | |
Inter UI Italic | 259kb | 95kb | 10kb | |
Roboto Regular | 172kb | 66kb | 9kb | |
Roboto Bold | 171kb | 67kb | 9kb | |
Roboto Italic | 174kb | 72kb | 11kb |
Front end code
The size of the front end code will vary a lot from project to project as it is largely unique to each website. However, off the shelf scripts are often used and can be factored into the budget. Tracking scripts in particular can add significant weight to a page and should be selected carefully. A few common examples are listed below.
Script | Front end weight |
JQuery | 33.4kb |
Google Analytics | 42.3kb |
Google Tag Manager | 39.4kb |
Matomo Analytics | 39.3kb |
HotJar | 92kb |
Gravity Forms | 13kb |
Algolia Elastic Search | 35.3kb |
Images
On most websites, images are make up the majority of the page weight. There are a huge number of variables that impact the weight of images on a page, including the number of images, the dimensions, the complexity of the images and the level of compression applied to the image file. The table below gives some indicative file sizes for a ‘medium complexity’ image saved at a variety of sizes and formats.
This information is useful for estimating page sizes and it shows that in general WebP is the most efficient image format, followed by JPG. However, there are exceptions to this depending on the unique properties of the image itself. The best way to know the size of an image is to save it at the required size and compression level, and test different file formats to see which is most efficient. What’s more, if the image is a simple vector graphic then an SVG file may be smaller than any of the image formats below.
Images | PNG | PNG Retina (2X) | JPG | JPG Retina (2X) | WEBP | WEBP Retina (2X) |
64 x 64 | 3.3kb | 9.0kb | 3.3kb | 9.7kb | 900b | 2.3kb |
128 x 128 | 8.5kb | 25.6kb | 9.7kb | 29.5kb | 2.4kb | 6.1kb |
humbnail 382 x 255 | 38.0kb | 128.0kb | 44.1kb | 78.7kb | 9.1kb | 24.1kb |
Medium Image 640 x 480 | 106.8kb | 350.6kb | 60.0kb | 145.9kb | 20.8kb | 56.7kb |
Banner 1200 x 500 | 172.8kb | 564.1kb | 136.7kb | 235.7kb | 28.3kb | 75.0kb |
Full screen 1440 x 900 | 354.5kb | 1.1mb | 148.9kb | 303.5kb | 54.3kb | 133.0kb |
Video
Video is less commonly used on websites than images, but in cases where it is used it can make the size of the other files on the page seem insignificant. It is also much harder to calculate because there are so many possible variations of file format, frame rates, resolutions and duration. The table below therefore only gives some rough indication of how big video files can be.
Video duration | HDV 1080 | h264 720 | MPEG-2 |
1 minute | 157MB | 371MB | 943MB |
5 minutes | 786MB | 1.8GB | 4.7GB |
20 minutes | 3.1GB | 7.4GB | 18.8GB |
60 minutes | 9.4GB | 22.3GB | 47.1GB |
Validate your budget
The above are helpful to understand the implications of decisions during design and development but you can never be entirely sure whether you have met the budget until the project is complete. At that point it is important to validate the page weight budget by measuring the final page weight using Chrome developer tools, or an app such as GT Metrix. These tools will also help you identify missed opportunities and allow you to make further improvements to the website.
Above all, whether you meet the budget or not, it’s important that the whole team learns about the impact of the decisions made along the way so that more informed choices can be made in the future.
Your handy checklist for setting and using Page Weight Budgets
Page weight budgets are a simple and highly effective tool to deliver websites that are not just more data efficient, but faster, more enjoyable to use, easier to access, and more sustainable. What’s not to like?
We’ve found that simply by introducing the concept of page weight budgets into our team discussions, we deliver more efficient work even on projects that for some reason don’t have a formal budget set. It has become a way of thinking and working that now guides our decisions whether we are conscious of it or not.
Here’s a handy recap of the steps involved:
- Introduce the team to page weight budgeting at the start of the project
- Take ownership of the budget as a Project Manager
- Formally agree the budget (or budget range) with all key stakeholders in writing before starting design
- Constantly review the budget and estimate progress throughout the design and development process
- Review the final size of key pages against the budget and learn from it
Do you need an incredibly efficient, fast website, or just want to chat about shared interests? Get in touch here.