I’ve seen in these last few years some people have published documents containing a checklist of things that we should watch out for regarding performance in frontend. In fact, front-end development is very complex and it is easy to forget things. So these checklists are valuable tools!
The SmashingMagazine has published a post with tips updated for 2020. Thank you, Vitaly Friedman! That is a great document! I particularly love the fact that it doesn’t focus only on technical directives (such as performance budget, removal of unused CSS, and delivery of WebP images), but also present non-technical guidance, such as “Establish a performance culture”.
Vital did a great job elevating the general concerns that each topic covered, presenting them in a way that goes beyond the implementation perspective and stepping into a more high-level architectural and critical mindset. Also, as a good architectural document, he was concise in his explanations and made it easy to navigate. If our architectural documents had those two traits people would consume them more.
What I would like to do now is to show how I would read Vitaly’s document from a Software Architecture perspective. If you are not sure what I mean by that, please read the sample of my book Professional Front-end Architecture. Here it goes:
- Since “premature optimization is the root of all evils”, it is important to instruct the developers on how to come about their responsibilities regarding performance. This idea goes hand-to-hand with the topic “Establish a performance culture”. Developers should be wise to know:
- Which performance concerns should be implemented since the beginning and what can be taken care of later on.
- What is cheaper/faster if taken care of since the beginning and what is expensive/time-consuming if taken care of later on.
- How can we help developers get this knowledge? We can’t simply assume that they know.
- More often than not, the definition of Metrics and Measuring Tools will impact multiple teams. Fact. So it could be valuable to define these standards on an “institutional level”, generating a guideline that is thoughtful and easy to understand. But we shouldn’t do it alone (as architects). We should involve many people, from all teams, to create the first version. After that, our work can continue by encouraging and capturing new ideas, keeping the document relevant and updated.
- Adding to what Vidaly said on the topic “Choose the right metrics”, it is important to say that metrics vary not only in importance to the users but also have different times of implementation and costs. Even the importance can be mistaken if we simply rely on the developers’ perception. We need to get the insights of UX teams and Managers as well since in many cases their visibility is better than others. In other words, “choose the right metrics” is right but subjective. Architects can help bridge this gap, connecting and investigating the multiple stakeholders’ perspectives to see which metrics are really worthy of investments of time and money.
In Software Architecture (and Front-end Architecture) a question that we should always ask is: What is the alternative? Based only on the three points mentioned, the alternative would be to let the developers judge the metrics and implement them as they find fit. However, if you are a programmer too, you know that these “performance optimization tasks” can take precious work-hours, which could turn out to be in a place that is less profitable.
Maybe you agree with me, maybe you don’t. Or maybe you think that what I am saying is too obvious. But the fact is that I often see Managers and Programmers too busy to pay attention to those things, and therefore making expensive mistakes in those very things. Having a management tool is just the beginning. After that, we will always need someone who will properly adapt and implement them in our work environment. Having a tool can be an illusion, indeed. And in our competitive world, every optimization of processes will give us an edge over our competitors.
A great example of that is the implementation of Agile: We can all follow an Agile methodology, but the companies that implement it better will harvest more benefits. The reality of how efficient and effective the implementation was is not always so perceptible.
Anyways, my goal was not to present a full architectural analysis of Vitaly’s document. My goal was to show you the kinds of thoughts that would cross the mind of an architect when examining a document like this. That is why it doesn’t matter if you agreed or not with my points. The goal is to show you the “kind of evaluations” an architecture would perform.
Step-by-step guides, checklists, manuals, and documents alike are very important but do not guarantee the success of any endeavor. Unlike coding manuals, every architectural and managerial document needs to be strategically reviewed and adapted in order to yield results. Who will optimize? What will be optimized? When to optimize? How much will it be optimized? Those are essential questions that we need to contrast with various information coming from people with company-wide visibility – which is something that engineers and developers not always have or can spend time doing.
You can know all of the ins and outs of a computer language (and their related technologies), and still not achieve success in your final product. Why? Because…
“Software Engineering helps us build things right.
Software Architecture helps us build the right things”.
In summary, it is essential for architects to evaluate those documents with critical eyes – or with wisdom, if you will – so we can take better decisions regarding the what, when, why, how, how much, of each thing we pursue. If the Managers and Developers have the time and knowledge necessary to investigate e and monitor those things, not only just one time but constantly, then that’s great! That is architectural work. Otherwise, a qualified front-end architect will be essential to keep the company effective and competitive through the wise usage of the technical resources.