JavaScript - we really do need to know how to make it go faster and take less memory. A book that promises this, promises much.

OK we all know the saying about optimization, which roughly translates as "don't do it". In practice, what generally matters is getting the right algorithm implemented in a sensible way. Easier said than done. For JavaScript, however, there are other issues because of inefficiencies in the way it connects to the rendered page and how it makes use of the slow connection to the server. There are most definitely things you can do to speed up a page load - the big problem is that not all of them are directly related to JavaScript. 

But this book is about JavaScript Performance, so let's discover what the secrets are. 

The first chapter is very general and starts off with a look at the HTTP protocol and TCP/IP, rendering, JavaScript engines and so on. There are also some very odd topics like a box out on conditional compilation with an example in JScript! At the end of the chapter you really don't know much more about JavaScript performance - just general details about how browsers work.

Chapter 2 is called "Tools and Technology to Measure and Impact Performance". This introduces you to Firebug and the network monitoring tab in particular. Other tools explained include YShow, WebPagetest, Minify, Closure compiler and R - yes, R the stats language. The idea is that you should know some R so that you can compare different results from benchmarking your web pages. Even though this only occupies 12 or so pages it seems like a complete detour. What the reader really wants are some ideas how to make JavaScript faster, not lessons in using statistics. 

Chapter 3 continues in the theme of benchmarking pages with a look at WPTRunner to automate performance testing. There is some more R and lots of listings that aren't particularly interesting or relevant. The chapter ends with an interview with the creator of WebPagetest. At this point you start to think that perhaps there isn't quite enough material to fill a book as thin as this 200 page volume.

The next chapter introduces perfLogger to explicitly benchmark JavaScript. and again we have more R to show us the results. Chapter 5 looks at the W3C's efforts to create a standard performance object. This is now fairly well supported by the latest browsers, but it isn't specifically about JavaScript performance.

Chapter 6 is the first that actually considers in detail what you might do to optimize page loading. It starts off with a look at how a page is rendered in detail. Next we look at script loading and async and spend a few pages working out how to measure the difference in speed. If the results were presented without the discussion of how they were arrived at this would be a very short chapter.

Chapter 7 looks at runtime performance and suggests among other things using a variable to keep an object reference rather than creating it each time. It also discusses jQuery looping versus JavaScript looping; jQuery DOM access versus JavaScript DOM access; the efficiency of Eval; batching up DOM access; and finally the cost of nested loops. Again a lot of the space is taken up with a description of how these things are compared and in most cases the only real shock is the size of the advantage. Most of the conclusions are fairly obvious and come down to "don't work something out more than once" and "JavaScript is faster than a framework".

The section on the cost of nested loops left me completely mystified. It starts with

"We know loops in general cost more in performance than unfurling the code and executing it sequentially. This is because each loop is synchronous and blocks execution of the rest of the application until it is complete"

This is true, but all JavaScript code is synchronous in this sense and even the "unfurled" version of the loop blocks execution of the rest of the application until it is complete. The overhead in a loop comes from the machinery needed to implement the index incrementation and testing for the exit condition and, of course, the "unfurled" version doesn't have this overhead. The section then goes on to show a set of for loops nested to depth 2,3,4 and 5 and the results show that the increase in time taken grows exponentially. If this is a surprise then you probably shouldn't be programming as each loop does L iterations. So the depth 2 loop does L² iterations, the 3-nested loop does L³ iterations and so on. Unwinding these loops is still going to produce a similar exponential increase in time taken because the work being done really does increase exponentially, no matter how you package it. This isn't surprising and is not a cause for concern nor optimization. 

The final chapter looks at balancing performance with code quality. This, of course, is the reason you should never optimize code because it makes it less readable. After a look at the idea of stripping out all the functions and modularity and writing your program as one big unreadable chunk, the chapter moves on to using the Closure compiler to do many of the same things but automatically. Here we are treated to a large listing of the sort of unreadable code that Closure creates - a few lines would have been fine but not the more than two pages allocated. 

This is not a book that will help you much with the task of optimizing JavaScript. At best it will help you figure out how to benchmark a web page. Given that the book is specifically about JavaScript performance, it spends a lot of time considering general matters and if you were to take out all of the material on benchmarking and using R it would be a much shorter book. What this means is that if you are hoping that it is going to tell you lots of things to do to make your JavaScript more efficient you are going to be disappointed. It tells you a few things but not as many as you might expect in a 200-page book. 

Only buy this if you want to know how to benchmark a web page.