chrome html javascript labs performance testing xtreme_labs_tech

JavaScript Performance and Debugging for Web Apps

As browsers on mobile and desktop progress, JavaScript on the client side has continuously become more robust and is powering a wide array of increasingly advanced applications. JavaScript applications are becoming larger and moving to mobile; both situations warrant a more serious look at performance than JavaScript implementations of the past.

Understand Your Environment

An important first step to writing great JavaScript apps is to understand the environment(s) your JavaScript code will be running in. You don’t need to fully grasp all of the internal workings of a JavaScript interpreter or optimizing compiler (especially since each browser’s JavaScript engine may differ) , but having a basic understanding of how Garbage Collection, Object Graphs, and Scope work in JavaScript can help greatly. John McCutchan & Loreena Lee of the Gmail team presented at Google I/O (and wrote a great article) about how to effectively manage memory, and touched on how understanding of these lower-level ideas can help.

Know How to Spot Red Flags

As McCutchan & Lee covered in their article and Google I/O talk, there are some situations which can be raised as red flags; areas of your application you can mark as key potential performance hogs. Excessive garbage collection often stems from using timers, frequent events, WebSockets, and any frequent operations; creating large amounts of objects in a closure will cause GC. You should watch how many objects you create inside of any function, but this need is multiplied n-fold by the frequency at which it is called, as you can cause slow downs by having frequent GC. GC halts execution in most popular browsers’ JavaScript engines, and too many of these GC pauses will hurt performance.

GC happens frequently when you create new objects very frequently and immediately stop using them. The memory profiler will show you a sawtooth graph when this occurs. Excessive GC isn't ideal, as execution is halted to collect.

The Angry Sawtooth of Excessive GC

Excessive usage of memory is often caused by a large pollution of global scope (sometimes a single missing var can cause an issue, as this will create a global variable), or by memory leaks; watch for large global objects assigned to the window object, which represents the global context.

Use Your Tools

Most modern browsers offer tools which provide insight into the memory usage of the JavaScript powering your Web Application. These Memory Profiler Tools which show a graph of memory usage over time can allow you to quickly check for the types of issues discussed earlier, providing a sort of “performance smell”. If you see that your application uses a large amount of memory, or usage increases rapidly and doesn’t fall (Memory Leak smell), or you see an angry saw-tooth pattern in a short span of a few seconds (Frequent Garbage Smell [gross!!]), this can be a sign you need to review sections of your app.

Write Performance Unit Tests

In some circumstances, it is warranted to explore the performance of a given unit of code you are writing. JSPerf is a useful online tool which runs performance tests on given blocks of code to determine which is faster. These can help you determine the performance costs of using different data structures or types of loops there’s a list of popular tests which cover a lot of common cases), and can often surprise you as describes in his article “Performance tuning as the art of weather forecast”. Knowing how a DOM operation performs, the best way to loop through data, or the expensiveness of multiple closures across environments can really help you fine-tune your JavaScript performance.

Helpful Links