small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

As a frontend developer, you are sometimes challenged with optimisation projects. 

Nowadays people perceive the web pages and Internet mostly visually. Apart from the design and pleasing visual appearance, websites need to stand out in areas like short loading time, smooth animations, and small payload.

You, the developer, might also know (or at least intuitively adopt) the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle)
, which more or less states that 20% of the effort generates 80% of the results. 

Sounds great, right? Do some coding, make things work, hand out results to the client, and make some cash. All is fine until the client requests the remaining 20% of the results - to make things pixel-perfect, super smooth, and generally outstanding. 

But sometimes there’s a catch.

**The code of other people**

On occasions, you might be asked to polish someone else's work.

This is precisely a situation that we sometimes encounter at Bitnoise. We improve good things so they become even better. We do the remaining 80% of the hard work so the client ultimately gets the last 20% of awesomeness. 

So what striving for perfection looks like? Well, as Pareto pointed out, it’s not easy. It requires discovering unknown unknowns and it takes a lot of resources (in the coding world - mostly time and money). But it’s worth the effort when excellence is at stake and the client accepts that.

**Where did 16 milliseconds go?**

Recently we got to work on the optimisation of a very nice looking website from Loaded, a gaming industry company. In the world of gaming everything has to be 60fps and smooth like butter. This definitely wasn’t the case with the webpage. The 3D content and layout animations were promising but when you visited the page on a not-the-most-expensive computer, the experience was far from optimal.

Animations were choppy, loading of the page took ages and the laptop fan was spinning so fast that your computer would almost fly away. 

However, when we looked into the code it seemed to be very well organised and structured. You could see at the first glance that it was made by someone who knows how to build a good frontend. We checked out who the original author was and indeed he was quite a respected and known developer on another continent. This was a bit intimidating. If he couldn’t make this site look perfect, how can we do it? But then we thought, “Well maybe he just did the 20% of the work and achieved 80% of the result”?

So we took the challenge and tracked down the pain points of the website. Fixing the performance wasn’t that easy though since it’s not really obvious if changes in existing code won’t break something in an unexpected way or place. Also, discovering what makes the animation degrade from optimal and sustainable 60fps is not trivial. In the process, you usually face code scattered with breakpoints, “console.logs” and “temporary solutions” in order to find out why it takes more than 16 milliseconds for the browser to render some of the animation frames. 

**Make the fan silent again**

In the case of our client's website, the bottleneck appeared to be the overuse of external JS library calculations. The internal workings of that library put too much unnecessary stress on CPU and GPU. The exact same effect could have been achieved with some handcrafted CSS styles and much simpler JS calculations. Modern browsers have quite outstanding optimisations of their CSS rendering algorithms that we as developers should leverage as much as possible. And in this case, we did. 

In the end, the performance boost was huge and the difference was like night and day. No more lost frames, no more low and inconsistent frame rates. And the fan got finally silent. 

There were also a couple of additional optimisations done in the webpage which helped to shorten the initial loading of the page and improve the user experience but the most impactful change was relatively small in terms of lines of code but huge in terms of client satisfaction. 

The lesson learned is that while Pareto is often a great friend, the law can also cause underwhelming results when we strive for a pixel-perfect frontend. At Bitnoise we believe in near ideal interfaces, that's why a 100/100 rule is often our guiding principle. 100% effort means 100% results.  



Dev Snapshot: Why is Pareto not Universal in Software Development

Marek

GET IN TOUCH