Your product deserves a performance budget
Performances should be everyone concern from strategists to software developers. It's not a must-have, it's a feature. Often the most critical feature of your web app.
In the past years, and even more today, new web technologies and browser features have helped us to make much powerful and fancy web app. Stakeholder requests have become more complexes and users need the better experience in every case. But, stick with modern consumer standards comes with a cost, and our platforms have become the mirror of our society: fat.
To avoid this, companies such as the BBC use performance budgets. Performance budgets are cost limits of web app performances. The base performance budget of the BBC is 12 seconds of load time in a GPRS equivalent bandwidth. Usually, a performance budget can be by load time length on a specific bandwidth, by page size, or even HTTP requests number, etc.
Performance is not a must-have, it's a feature.
Your performance budget type is according to your needs or business cases. The aim of this budget is to provide for your team a framework, a scope, for your next projects. You can either apply this budget on your legacy applications and transform this budget to a goal for your team.
Performance budgets should be considered next to your project or feature cost, and stakeholders need to be warned if their needs have a risk to reach the performance budget. It'll not be easy to predict the performance budget of every demand, but it's technically the same difficulty as the financial cost, just a little less traditional.
Product designers need to work with performance in mind
Another focus should be done on design teams. In the standard industry workflow, the design team works with the frontend team to build the application design. Frontend guys are often here to “prevent” design guys from being too creative, to prevent design guys from being too performance expensive. A performance cost part, and not the less, come from the application design (remember the skeuomorphism).
I didn't mean that product designers don't care about performance, they become more and more concerned by the technical part of their design. But, the role of UI developers is to help them with this task.
In product design, size matters.
The Mobile First philosophy teaches ourselves that every development should be thought with mobile constraints. I'll not speak about this philosophy in details here but, it's important for designers and developers to focus on mobile. If you build your application for mobile in first, you'll consider performance as a first-class objective. Then, when you build your application for bigger screens, you'll keep this objective in mind. Because mobile needs to be careful with performance, space, and content presentation, design, and habits are going to adapt themselves in an unconscious way.
The Flat Design concept, following by the Google Material Design guidelines, remove the most performance expensive UI features to focus on usability and clarity. So, it's a good practice to work with those guidelines in mind for your next application.
In product design, size matters. Size impacts usability, user experience and feeling about your product. In the web, the material is virtual, but your interface is real. You must think your UI as a physical thing, and as every physical thing, a heavy one is more difficult to use. Your application features deserve the right weight for the right task.
Performance is not only about product quality
Application performance is not a big developer trip on quality but, it has a big impact on your product conversions if you skip it to your strategic decisions.
As Amazon said: each additional 100ms in load time reduce their conversions by 1%.
You should think about mobile bandwidth and mobility. You cannot only focus on a USA fiber bandwidth when you talk about Wi-Fi. Wi-Fi is tricky because it can be extremely variable depending on the location. Your home Wi-Fi is probably nice, but probably not the airport Wi-Fi, or the MacDonald Wi-Fi. And you can think about 3G bandwidth too. It is very volatile. There is a regular 3G and a good 3G, and there is a 250kbps difference between them, with 60ms RTT.
Performance impacts directly the user experience and a good user experience improves conversions. So performance has a direct influence on your application profitability.
Working for performance will improve each part of your development process
If you can keep performance in mind for each development, every part of your application will be improved in quality. To reach a performance budget, developers and designers need to work with efficiency, rethinking their processes and manners.
Developers are forced to program top quality scripts and to monitor apps. Compression and minification techniques will be strictly used, bandwidth and network hits will be reduced, so as the server or CDN cost. Caching will be used in details. It can open the opportunity to think about an Offline-first philosophy, which can take your product to the next level of optimization.
Designers are focusing on usability than purely visual features. Remembering that user experience is critical. Designs will be mobile proof, so simplicity will become the new guideline. Keep it simple.
Users will thank you for considering application performance, and will always choose your product for this. Your product can now access a powerful and demanding market as a serious competitor.
A performance budget is a powerful tool to define a goal for your application. Teams are inspired by this goal, to improve their processes and to build the next product generation. Conversion rates are directly influenced by performance, it's a good investment to consider in a mobile and fast consuming the world.
Let's discuss building better companies.
You have better chances of finding me active on Twitter. I tweet about leadership, remote work, software engineering, personal growth, and systems. I also build my company publicly.
I'm also active on LinkedIn, where I post longer thoughts.
You can also contact me by email.
The handbook-first approach
Distributed teams must consolidate tribal knowledge into documentation. To solve this, let me introduce you to the handbook-first approach.
I decided to pivot my business
The world is crumbling under exponential complexity, diverting and consuming people's attention for the worse and generating tons of process waste. A story on why I pivot my business.
Why I advocate working from anywhere
The story of how I came to advocate remote work and swore to solve its challenges as an entrepreneur through the prism of my recent family history and origins.
Building trust early with an introduction letter to my teams
A very honest attempt to be more transparent about me to quickly build trust with my teams.
Who am I—a story on personal growth
I always been attracted by the concept of personal growth: getting to know yourself and working on it to reach your full potential.
Distribute features by executing in cycles
A straightforward product development approach builds around six-week cycles separated by two-week cool-down periods, inspired by Basecamp techniques.
A system attempt for startup studios
One of the greatest force of a startup studio is the powerful intellectual property (IP) that it owns, which unlock startup scalability potential, engineer and customer high-quality experiences, and massive business technological strike capacities.