Front End Website Optimization: Garbage Collection

Introducing the third post from our Front End guru, Dekus Lam. Dekus is the go-to problem solver for Resolute’s ambitious Front End Web Developer team. In this series, he aims to describe what makes optimizing Front End so crucial in today’s increasingly innovative web design world.

There are tons of articles and tutorials on the web that provide recommendations about how to make your website faster. In addition, there are also many awesome tools such as YSlow, Google PageSpeed Insights (esp. Critical Path Explorer), webpagetest.org, Yottaa. These tools check whether you are serving a compressed (gzip) minified version of your CSS and JavaScript files, or using CDN to host common libraries that your website happens to use. However, these nuances are not what this Front-End series will address.

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.

Garbage Collection

In JavaScript, we do not have the ability to manually invoke the allocation and de-allocation of objects in the heap. Garbage collection (GC) is designed to collect all the non-reachable objects (not otherwise referenced) and free their memory. The bottom line is that your codes do not have memory leaks, which GC will not take care of.

You might think that memory leak is worthier than garbage collection to discuss from a performance perspective. But the worst-case scenario with memory leak pattern is references or variables retained in closure. Due to a few common bad practices, there are already plenty of resources on the web targeting memory leaks and better practices about how to prevent them.

Garbage collection mostly runs 1) when memory shortages cause allocation failure, and 2) when the web page/app is idle. When GC runs, the JavaScript process will need to halt. But the timing is crucial! We don’t really question the second case because it will be trivial and GC should run only once (typically a scavenge GC, followed by mark-sweep GC, or possibly a mark-compact GC depending on the implementation and conditions of the heap) until user activity occurs again. The first case is extremely important, and cannot be left out if anyone wants to write faster JavaScript. Let’s say you have to implement a slideshow application, which will display a different subset of slides depending on which section the user is has currently navigated to. As soon as the user has reached the last slide of one section, he/she can navigate to the first slide of the next section, and will be able to navigate back to those old slides later on. Almost every individual slide will have some sort of custom animation and interactivities. So you will have big objects for the slides and smaller objects for the components on the slides. If the overall number of slides is large, GC will be invoked at some points during the application’s runtime because the heap may be running low on memory. It could be a fast scavenge GC on the new space logical region of the heap, or a relatively slower mark-sweep one, which is performed on the old space depending on heuristics and current heap stats, like the amount of wasted space and fragmentation level, something lower level that some Front-End developers just ignore. Typically a GC can take < 100ms for a fast one while a slow one can cost > 300ms or even > 1000ms to defragment and move objects around in the heap.

Author
Adam Chalemian
Director, Technology
Posted
07.03.13
Adam Chalemian
Director, Technology

Adam joined Resolute Digital in August 2010 as the Director of Technology. A former US Army Cavalry Officer, Adam enjoys leading, mentoring and teaching the talented team of Resolute developers. Adam graduated from Valley Forge Military Academy and Villanova University with a degree in Cognitive Science.

Contact Adam