0
0
It is a short step from web performance to performance budget: concrete examples of a “new” way of working on the web.
A few months ago we talked about web performance , a fundamental activity for online business. Now we know what is meant and why it is a relevant topic for a project, as well as what are the tools that allow us to analyze and monitor its progress. But in practice, the question remains: our site or project currently has a certain level of performance and we would like to make it faster . How to do?
From Web performance to Performance budget
Let’s start with a concrete example . Let’s say our site has a loading speed of 4 seconds and a Google speed insight score of 59%. Not bad as a result, but we want to make some improvements. What do we have to do?
First of all, we must be sure that our project, on the technical side, makes the best use of all good practices to increase its speed . A server set in an optimal way, a code (css + html + js) concatenated, minified, perhaps zipped in GZIP format, are the basis.
Since the frontend is one of the biggest critical points, maybe we can choose some small strategies to increase efficiency: use compressed images, use CDN to distribute our code, limit or optimize the use of custom fonts, upload images through “Lazy-loading” and so on. Without going into technical issues now, we can also keep under control what is called ” Critical Path ” or ” Critical Css ” of our frontend code and try to improve it with tools like Penthouse or CriticalJS
If we have done everything right, after some small technical improvements we will see some progress with respect to the speed of our site. But the technical side isn’t the only part we need to work on .
Each project has its “why”
In the real world, each project, or client, or website has its own characteristics, its own history, its own objectives. What applies to one site cannot automatically apply to another. A trivial example: an ecommerce site is very different from a site for a company that produces cookies. Each of them will have a concept, a graphics, an implementation of well-defined and probably very different features.
At a technical level we can configure a common base of technologies and code, but this is not enough. At some point one of these sites will require a feature that will make the site slower and lower its web performance : for example a fullscreen carousel on the homepage .
At this point what to do? All of your web performance strategies and getting the site loaded in less than two seconds will be put at risk. How to try to avoid this?
It’s not always just a question of “speed”
The term is quite simple: define a “budget” for your performance . Here’s how its “creator” Tim Kadlec defines it:
Nice definition: but what does it actually mean? Basically for a project you start setting a “budget” and try not to exceed it. For example, the maximum load time for the page. Going back to our example of a new feature related to a carousel: if the feature makes your homepage too slow, thus “breaking” the budget that you had set for loading the page, do not implement the carousel.
I already know what you are thinking: “Should I really go to a prospective client or colleague from tomorrow and tell him not to implement a carousel because he goes beyond something called the Performance Budget?”
The answer is complicated. But it is YES .
What is the “Performance Budget” and how does it work
If a web project really has priority on the loading speed of its pages, because it translates into greater economic revenue and more interaction with users, it is time to talk seriously about Performance Budget and how this concept can change the workflow. .
Because basically the Performance Budget is not a technical concept, but a real working model that always keeps web performance in mind and concretely modifies the way of thinking about a project, from design to development to resource management. .
The concept of Performance Budget is based on technical elements, but its effects affect not so much the world of computers but the world of the people you work with and who use a website. If all the people involved in a project accept or believe in web performance, having a common basis on what it means, what it implies and what it could bring, then the changes will never be considered wrong.
The Web Performance, the analysis of page loading speed, sites such as Google’s Speed Insight are “only” tools that offer you and your colleagues technical data. The Performance Budget is what comes next: a working approach that, using this data, offers strategies for managing a project . Here is a simple example of using Performance Budget: a Performance Budget Calculator
As you can see, the inputs can be few, simple and easily understandable: in how many seconds your page must load with a certain type of connection. With one click you will have your Performance Budget, in a simple and objective data: kilobytes. And you can try to “balance” the accounts by allocating the bytes in this or that element (css, js etc ..). Like with a blanket in cold weather, pulling on one side risks leaving another area uncovered. And it will be up to you to decide where and how to find a balance.
Based on the choices, based on technical and objective data, you will have created a working strategy : have you reduced the bytes for the fonts? The design can no longer be based on 3 custom fonts but only on one. Did you increase the bytes for the images? Ok, now you can have your carousel, but maybe you will have to remove the Google map at the bottom of the page to “recover” precious bytes. And these choices will have to be discussed and accepted not by computers, but by people like the colleague, the boss, the customer.
A common basis to better guide the choices
All this will not always be easy , indeed probably very often this kind of strategies will encounter obstacles and maybe even be ignored. Talking about Performance Budget forces all people working on a project to have a common basis on web performances and their importance, as well as being ready to change their way of working based on technical data such as “bytes” and ” speed . loading a page “.
But if you are really interested in the topic of Web Performances, setting a “Budget” for them will become a priority. And making these strategies and information known to the people you work with will also be part of the plan.
To conclude, below is a video dedicated to “ performance culture ” where Paul Lewis and Lara Swanson , performance experts for Google and Etsy respectively, talk about how they directly influence the choices of their companies. To note: their intervention speaks not so much of technical problems, but of problems between people and use of the web .
Because basically a fast web page is technically a wonderful thing. But without a user happy to see it, there is still a series of bytes lost in the sidereal cold of the web .
