DevTools/Planning/Performance/Details

Performance Overview

To optimize the performance of an html5 and JS based web application, we need three general pieces of information, each of which requires slightly different tools:

1) What's slowing down execution
What it really comes down to is how well the application responds and flows. So we are basically looking for slowdowns in frame rates and looking for the root causes of those slow downs. Those root causes generally come from three sources:

• a) Excessive DOM and graphical changes coming from JS execution
• b) Excessive DOM and graphical changes coming from unoptimized HTML5 and CSS
• c) Unoptimized JS code itself, i.e. the code just takes too long to run
• d) Unoptimized JS execution (baseline versus ionmonkey)
• e) Unoptimized garbage collection: if we keep releasing a lot of objects, GC will run more frequently

The right tooling will instrument as lightly as possible in order to minimize impact on performance and will provide a time-based view of execution. Mostly, as a developer, I want to find out where my application is slowing down (frame rate) and why (where is my application spending time when the frame rate slows down.)

2) What's increasing memory consumption
When the browser was king, web apps could run on desktops and laptops where memory was really not much of a consideration, especially when it came to writing client-side apps. But with the proliferation of mobile devices and the push towards cheaper devices, memory is a premium and can no longer be taken for granted. Hence there is a need for tools that can tell us about our application's memory consumption and clues on how to minimize it.

In general, optimizing memory is really about counting object instances. There are several different types of memory optimizations that need to be done:

• Short term memory leaks (Google calls this "scattered objects" or "Action cleanness".)
• DOM Leaks, i.e. Orphaned DOM fragments that keep increasing after specific events
• Long term memory leaks, i.e. less obvious leaks that take 5 minutes or more to increase to a measurable level.
• Overall memory footprint reduction - an app. may not have any "leaks" but may still be a glutton for memory.

That's about it, and it should not be more complicated than that.

Product Design Challenges

Memory and application