Three ways we’ve optimized Gliffy HTML5 (and avoided Nerd Rage!)

By Rocco Balsamo on Nov 13, 2012 in Gliffy, Let's Talk Tech

We wanted to make Gliffy as snappy as possible for our HTML5 Confluence Plugin launch, so we dedicated a small portion of our resources to optimization. In this post I’m going to outline a few of the techniques we used for optimizing the front end, and hopefully you can apply these techniques to do smart and focused optimization.

Optimize for Programmer Time
In many instances the most limited resource in a software product is neither processor speed nor memory, but engineers and their time.

Famed indie game developer Jonathan Blow (Braid) has a great talk about optimizing for programmer time. He explains an anecdote about some nerd rage he encountered when viewing the “lazy” linear-search based loading code for Doom:

doom-original-coverTheir implementation was totally the dumbest thing. Start at the beginning of the file, don’t even unpack anything, scan the file till you find the thing. And that’s absolutely right... If you profile the loading code of Doom, it turns out the amount of time in this string lookup is negligible.

Most code is not performance sensitive. At Gliffy we write code simply and effectively and worry about any performance hits after the simple data structures and algorithms we use show up on a profiler.

Optimize for User Experience
After the HTML5 editor was close to feature complete, we loaded up some large diagrams and noticed long pauses and lockups on initial load as well as zoom. This makes sense because these are the times that the scene needs to be fully rendered.

We used the work queue pattern to avoid these lockups, and allow us to show an animating loading spinner during potentially long render cycles. On a complete re-render:

For implementation of the work queue, we used jQuery.queue(). There is a nice
article on queue in StackOverflow.

This technique allows the animated spinner to animate, and for individual nodes to pop in as they render. This improved usability and browser responsiveness.

Don’t be too smart!
The moral of this story is that you should heavily prefer simple, unoptimized code for first pass. If we pre-optimized, amortizing over the life of the project, we would have wasted weeks of programmer time for little gain. We would have more convoluted code that is difficult to debug.

And a little loading time is OK. Just make sure not to hang the browser, and give your users a clear indication that work is being done.

Be on the lookout for part two of this post where I will get down to the nitty gritty of optimizing for speed and using a profiler. In the meantime, go ahead and draw your own awesome optimization diagrams in Gliffy Online!

Read Part 2!