The Chronology of a Click, Part XI

In his February 2012 follow-up, Steve ran some tests to see if his 80/20 measurement, which he calls The Performance Golden Rule, still applies. It does.

These published results are not overly relevant to us because we are concerned with our website, not an average taken from some preselected set of websites. However, Steve does give us a simple method to approximate back-end time. Simply measure the time to first byte.

Several authors have suggested that optimization efforts should focus on front-end performance because that’s where most of the time is spent. While I expect they are right almost all the time, there are cases where optimizing the back end should not be ignored. Remember, the front end handles one request at a time, but the back end can handle hundreds, thousands, or more in that same time.

Here’s a suggestion for a starting point: Set a limit of 500 milliseconds for the back end and 1,500 milliseconds for the front end. If you don’t like my numbers, that’s okay, but make sure you define your own. Then go to work on anything that takes longer, whether it’s back end or front end.

• Use a profiler, a code-checking tool, and a third party to evaluate the code before transferring it to production.
• Eliminate allmemory leaks. Objects, properties, connections, processes, etc. should be deleted when you’re done with them. Never rely on a garbage collector to do this. Add more memory if you must, but first locate and fix the bad code that caused the problem.
• Inline function calls as much as possible, but watch out for the time-space tradeoff. If you inline everything, the code bloat may be unbearable.
• Everything that can be done outside the loop should be done outside the loop.
• Avoid heavy nesting.
• Comply with all standards.
• Compiled code executes faster than interpreted code. [JavaScript is interpreted, but how can you avoid it? See below.]
• When dealing with interpreted code (like JavaScript), run it through a minifier to remove comments and extraneous white space.
• Use local variables instead of global variables.
• Use memoization to cache the results of time-consuming processes.
• Use primitive operators instead of function calls.
• Whenever possible, unroll the loop. Example: Use j++;j++;j++;j++;j++; instead of i=5; while(i–) j++;. [Of course, in this case, j+=5;would be much better.]
• Use x=a.length before the loop and i<x as the loop condition rather than using i<a.length as the loop condition.

• Do not use eval. If you must use eval, pass it a function instead of a string.
• Use a for loop instead of a for…in loop whenever possible.
• Avoid with.
• Pass a function instead of a string to SetInterval() or SetTimeOut().
• Avoid anything not included in ECMA-262, 5th Edition strict mode.
• Whenever possible, avoid new. Use “xxx” instead of new String(“xxx”). Use {} instead of new Object. Use [] instead of new Array. [try it]
• Don’t use global variables. If you must use one extensively, assign it to a local variable and use the local variable instead.
• Use var. Example: Use var i = 0; instead of i = 0;.
• This tip “use x += “a”; x += “b”; instead of x += “a” + “b” to avoid creating a temporary string” used to be true, but with recent browsers, the opposite is now true. [See this jsperf test.]
• String literals are often faster than string objects. Measure your code’s performance both ways, then choose the fastest. [example]
• Optimize the order of conditional expressions to take advantage of short-circuit evaluation. Example: Use a && b instead of b && a if a is likely to be false more often than b.
• Minify. Long identifiers (the name, not the value) require more processing time, so shorten them to one or two characters. Remove comments and extraneous white space. Minification should be done during the build process so we can keep the original source code for the developers and serve the minified version to the end users.
• Use === instead of ==.
• Keep try…catch out of performance critical code.
• Do not create setters/getters that do nothing more than set/get a value.

By definition, JavaScript is interpreted rather than compiled.

JavaScript can also access the DOM tree directly. It can add, modify, and delete nodes to its heart’s content. It can even make decisions based on the contents of the DOM tree.

JavaScript code is executed serially when it is received. During execution it blocks rendering and some downloading. However, JavaScript can use XMLHttpRequest to download components and data from the server during execution. This can be done serially or concurrently.

Try this as a skeleton for JavaScript programs. Let me know how it works for you.

  issue XMLHttpRequests for the needed-now JavaScripts
  issue XMLHttpRequests for the images
  issue XMLHttpRequests for the dynamic data
  issue XMLHttpRequests for the needed-later JavaScripts
  while waiting for those downloads:
    download the style sheets
    build the web page
  when onLoad is triggered:
    wait for, then handle, the downloads as they arrive

Note 1: The needed-now JavaScripts are the ones that should be executed before the user starts interacting with the web page. The needed-later JavaScripts are the ones that will execute in response to a user-generated event.

Note 2: Use absolute positioning/sizing for all divs, iframes, tables, and any other rectangles that may affect layout.

Note 3: If the downloads must be handled in a specific order, the programmer must provide the logic programmatically. The downloads may arrive back at the client in any order.

Note 4: You might find a slightly different order better. If so, use that. The basic concept is to request as many concurrent downloads as possible, then build the skeleton of the web page, then deal with the downloads in the correct order (which may or may not be the order in which they arrive).

JavaScript provides everything imaginable, and then some. There are often multiple ways to do something. Some of those options are faster than the others.

However, be wary of the trickster. Some coding options seem to be the fastest, but they are only the fastest in certain situations. Knowing they’re fast isn’t good enough; we have to know in which situations they are the fastest.

JavaScript is interpreted, not compiled. Compiling is faster than interpreting. Opcode caching gets us part way there, but not all the way.

JavaScript does not offer concurrent execution; it executes serially. Exception: XMLHttpRequest lets us concurrently download data, HTML, JavaScript, images, stylesheets, or any stream of bytes we want. The download happens while JavaScript continues executing.

For more JavaScript performance tips, read my previously published Website Performance: JavaScript (which also includes tips about rendering, CSS, and the DOM).

As for rendering,  …to be continued in Part XII.