The harder web optimisation problem: How to actually get it done
Making sure performance is not treated like a step-child and gets a seat on the table
Let’s talk about performance optimisation on web. I assume if you’re reading this, you’re web engineer or are interested in web development topics. But before we begin, a little context about what I mean here when I say performance optimisation.
This is about the high level idea of performance that is determined by how fast your website/app loads and how to maintain that.
Although very important and in part contributing to the topic at hand, we won’t be focusing on things like how computationally performant your actual code is inside a module for instance.
With that out of the way, I think it is fair to say that web performance today is increasingly becoming crucial to focus on than in the past few years. Users’ perceptions of, and expectations from a website have changed; which does matter a lot. Meanwhile, Google has been raising the bar for what performant websites look like with the aggressive push of Web Vitals, and how not focusing on them can prove costly.
Moreover, for a organisation like Noon, which is out to make good education not just accessible, but highly engaging, it becomes crucial. With a goal to impact 50 million students by 2023; and a focus on wide range of users like India’s, how our platform and product performs can very well define how easy or difficult our way forward is. A live online classroom that runs smoothly on an entry level android device and a platform that inspires confidence in teachers to teach students from anywhere, can and will have a huge impact on how online education is shaped. For that, performance will have to be integral part of the journey.
There are a lot of good stories and write-ups available across the web on how to optimise the performance of web apps. Some are all-encompassing, while others talk about specific problem at great detail. In this article though, I want to focus on the process rather than the technical side of performance optimisation.
I want to talk about how to make sure performance is an integral part of your focus within a fast paced product development ecosystem that you are working in.
#Performance often goes with #WeHaveToFixThat. But in order to actually start working on it from zero takes a thought change and a few other incremental steps building on top of that. To start with,
Remember who you are building for
As cliché as it sounds; you are not your consumer, your product team is not your consumer, neither are your investors.
Your consumer is sitting in a tier 2/3 city with a weak mobile phone network and no wifi.
At least that’s a portion or our consumers/users. Yours could be fairly similar; and that’s what you don’t have to forget.
Simulate as real conditions as you can for testing for your lowest common denominator (LCD). By thinking about and solving for your LCD, you’ll be fixing things for most of your users much before you’ve optimised for the target user.
You can get some simulated data from you average lighthouse tab on chromium based browsers, or through the lighthouse cli (with finer controls). In addition, I’d also suggest manually simulating as real world unfavourable conditions per your LCD as possible. That could involve getting hold of an older generation or an absolutely entry level android phone, and moving to that corner of your home/office which has the least network coverage and checking there.
Start small, share your progress
In the fast paced agile development cycle, performance is recognised as something that matters, but not something that’s crucial ‘at the moment’. Until… it is needed. Sometimes things do shake up a little and a proposal document detailing what needs to be fixed is created, but that takes up a sprint and things don’t always move further.
How to fix this?
First of all, don’t attempt it on the side. That’s the easiest way to get it right back into the backlog.
- Ask your manager/lead to give you a week’s time
- Start small. Pick the low hanging fruits. See what you can get done in that time
- Share the outcome/discoveries with the team
Focusing on essentials is incredibly, well, essential here. Steve Sonders shares some rules for performant websites in his book and a lot of them are things just right to easily start with (comparatively), depending on which architecture you currently follow.
Sharing here, is vital. Whether the week long experiment had an impact on your lighthouse scores or not, share it with the team. Even if it was a negative impact. By sharing your choices, process, and the challenges you faced, you’ll both create interest within your team, and start a discussion around other optimisations that can be done within your project. This will in turn help you keep the progress on.
It is worth mentioning that the end goal is not improving page-load speeds, but how those improvements eventually affects engagement of users and benefits KPIs. Initial experiments will also help you get metrics on how the optimisation efforts have and would help business going forward.
Set Performance Budgets
What happens when you’ve tackled all the glaring issues through your efforts and turned lighthouse circles all neon green?
A google internal study in 2019 found out that 40% of the brands regress on web performance after 6 months.
To avoid repeating the cycle again after 6 months, the best way forward is to set Performance budgets. Here is a definition of performance budgets from Milica Mihajlija’s write-up on the same topic.
A performance budget is a set of limits imposed on metrics that affect site performance. This could be the total size of a page, the time it takes to load on a mobile network, or even the number of HTTP requests that are sent.
This brings in the cultural aspect of this whole topic. Optimising performance is not an exercise in isolation, it will ultimately have to become part of the culture of your team and your organisation in order to consistently deliver good experience to the user.
You can setup budgets at different steps of the pipeline. A good place to start is to simply set quantity/size or milestone/time based baselines using lighthouse cli and run lighthouse through the config that you set at build time.
You can take it further and automate the process for your CI pipeline so that your team always knows the performance cost of a new feature and you don’t accidentally send out something that breaks your baseline budget.
Having a look at your competitors performance metrics would also help you set this baseline.
Push for a performance culture
You’ve optimised your scripts, assets, reworked your fetching and caching mechanism. You’ve also setup a automated check in your CI pipeline. But how will you foresee an additional script added to GTM by the marketing team that is going to double the revenue for sure? How about the next 5 scripts added by other teams?
As you’ve seen building up till now, the success of solving the performance problem more and more depends on the culture of the team and of the organisation at large. Sharing the importance of, educating, and bringing everyone onboard is as important as deferring the load of third party JS bundles.
The product & design team needs to be onboard in order to have a performant designs, specially if there aren’t any fixed design guidelines or a design system. As would the the growth, marketing teams and similar teams. One good way to make sure that happens, is again, to share your reasons, efforts and progress so far. To keep it alive in the conversation.
Finally, try to get it included in your KPIs for the quarter/year to further solidify it.
Closing remarks
I drew this story from my recent experience here at Noon Academy. I was going to hash out the journey that we’ve had so far on the path of web performance at a low level. What were the exact problems that we faced, what optimisations did we do and what are the things that are still left to be tackled, etc. But I felt that was quite similar to a lot of other stories out there.
This, on the other hand, is not something that a lot of people have talked about. I feel it is important not just for us at Noon, but for everyone; specially due to users changing expectations on it, the bar for good performance is higher than ever before.
Thanks for reading. We will be sharing more from our performance journey in the weeks to come.
