Being a Front-End developer today is not easy, at all.
With HTML5 and CSS3, the web is becoming much cooler than it was in the late 90s and early 2000s. We are now in the age of user experience. With the rising market shares of mobile and tablet devices, and the dramatic growth rate of mobile commerce sales, the way websites feel is as important as how the look in order to provide the best user experience to visitors and consumers. Writing faster high-performing codes will not only lead to user experience satisfaction but will also improve marketing metrics and values, according to studies and statistics published from giants, such as Google, Amazon.com, Yahoo, etc.
The key parts of optimizing Front-End performance rely on understanding how the browser actually works as a whole. I will briefly go over some very important elements, which most people forget to consider.
DOM Rendering & Hardware Acceleration
After the construction of the DOM tree, we should have all the DOM elements and their associated CSS properties in place. Then we have something called the software rasterizer, which will rasterize pixels of what you will see the in the screen to a separate bitmap, which is stored in the memory. Now these DOM elements will either go on the software-rendering path, which is done by CPU, or the composited rendering path, which GPU rules based on whether they were promoted to composited layer and handled by the compositor that knows everything about 3D.
By smartly applying hardware acceleration to those elements that need smooth rendering, we can reduce the tax burden on the CPU and use the freed clock cycles for something else.
It’s said that “With great power comes great responsibility” and as such, we should not abuse the power of the GPU or foolishly think that the GPU is going to make your webpage run faster without sacrifices. The fact is that, those bitmaps that sit in the memory will be re-rasterized again as soon as their “in-frame” DOM elements experience a visual change, a process called “repaint”. Then these changed bitmaps will be re-uploaded to the GPU. But, the memory bandwidth of the transfer is not free. As a worst-case scenario, let’s say you have implemented parallax scrolling on the webpage on which some elements will move around or resize themselves, as you scroll up and down. Every time these elements “transform”, the bitmaps in the memory will be rasterized again. And based on the actual view size of the elements, there may be more bitmaps involved in the process of rasterization and uploading. Some people may make an argument saying that the process will be lightweight since some browsers are slicing the views into tiles and uploading them only when necessary. The answer is Yes and No, and it depends. Assuming many of these elements have CSS box-shadow(s) and border-radius on at the same time, will you still think the processes are lightweight?
On the other hand, making too many hardware accelerated DOM elements will definitely consume more VRAM on the GPU. This is significant especially on a mobile device. Once you run out of VRAM, your mobile device experience will lag significantly.