Speed Is Not As Important As You Think It Is

The JavaScript landscape has been changing, especially the past few years. Just like when AJAX made web developers rethink what could be done with the platform, the wave of new, fast JIT-compiled JavaScript engines has us rethinking performance. Even IE is getting on board the performance train!

For the most part, this is a good thing. However, there seems to be a lot of attention to hyper-optimizing JavaScript applications, to the point of excess. More and more I’m seeing efforts to fine tune small details – expanding simple code and making it complex – all in the name of performance, without stopping to think if they should. There’s a lot of time wasted on saving milliseconds (if even that) of execution time because unit tests reward their efforts. A unit test may show that Code A is 50% slower than Code B, but when Code A only takes a few milliseconds in the first place it’s usually irrelevant, especially when Joe User likely won’t notice or appreciate it.

JavaScript programmers (and programmers in general) need to learn that they should only optimize when forced to do so, and instead focus on writing elegant, readable, and – most importantly – maintainable code. And if it happens to be a very efficient way of doing it then great! But adding code complexity in the interest of efficiency should only be done when performance is genuinely hurting the user experience. In most cases you honestly shouldn’t need to do any optimization after the fact, as long as you follow standard practice and think your problems through before writing sloppy code.

If you do need to make adjustments to improve application latency, however, then I do have one tip: ignore the little details. It’s in fact very likely that you can go back and fine tune many places in your application where you can change a few lines and cut the execution time of that particular action in half. But that’s not where your focus should be. You should be focusing on the problem areas in question, what performance profiling tools are made to do. Figure out where most of your slowdown is: it probably isn’t in some function that gets calculated once or twice, instead it will almost always be in commonly used functions and objects or other major segments of the application architecture. In fact, it’s much more likely that the way you structured the application is the speed crutch, rather than tiny details.

I fear this obsession with micro-managing performance will drive us all insane, especially when a minor speed enhancement in one browser can mean significant performance loss in another. These things really should be left to the engine architects like Google and Mozilla, not the JavaScript developers. JavaScript programmers should pave the way towards beautiful solutions, not highly optimized ones.