A note on JavaScript performance

There’s a lot of focus on the performance of JavaScript in modern web applications. Sites are routinely panned for being too slow, using too much JavaScript, and interacting sluggishly. There’s a lot of talk about this library being too big, that application using too much code, etc. Typically, the suggested solutions are:

  • Crunch your code. Using a processor to strip out extra white space, comments, and anything else reduces the overall size of the code. This is the traditional way of doing things.
  • Compress your file. Lately, a lot of people have suggested compressing the JavaScript file using gzip, which significantly reduces the file’s size on the wire, moreso than simply removing excess characters.
  • Do both! The ultimate is to use both of these techniques to reduce the file size as much as possible.

There approaches are all fine for doing a single job: hastening transmission time from server to client. Once the code gets to the client, though, it doesn’t matter how compressed it is. The JavaScript interpreter knows nothing about compression. It simply needs to parse, build a syntax tree, and then execute the code. This means that the more code there is, the slower the execution. The bits that you saved on the wire mean nothing at this point, you need to optimize your code.

My general rule of thumb is that less code is better. I’m not talking about bytes or replacing variable names with shorter ones, I’m talking about the number of statements in your code. The more statements, the slower the execution. There seems to be a misconception these days that you can make your JavaScript code as big as you want because the files can always be compressed and crunched, but you need to realize that code execution is a function of code mass. Long-running functions can cause severe performance problems and lead to the dreaded “A script is causing this page to run slowly” dialog.

So, a plea from a single voice: don’t forget about optimizing your code the old-fashioned way by removing excess and unused functions, avoiding calls to functions that only execute a single statement, and keep your code weight down. You’ll be happy that you did.

Comments

  1. Richy

    Here here!

    I think these days that code optimisation is too often treated almost like a bad word - certainly in the desktop world. And to a certain extent that's fair enough in that context, because machines are always getting more powerful, memory is always getting cheaper and compilers are always getting better at optimising code anyway, so why should "I" have to bother.

    That attitude won't wash online, where every byte adds to the download time, and every statement adds to execution time. Even going beyond pure lines of code, it's amazing how many times I've seen code like:

    while (i < someFunctionThatWontChange()) {
    // do stuff;
    }

    instead of the much more efficient (in general):

    var aval = someFunctionThatWontChange();
    while (i < aval) {
    // do stuff;
    }

    In fact, I've even seen coding standards which actively encourage the former, because it's less lines of code and easier to understand!

    Grrrrr

  2. Nicholas C. Zakas

    @Richy - I've seen similar suggestions about optimization. This is just the beginnings of a crusade I'm going on for making JavaScript more efficient and maintainable. More to come!

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.