JavaScript: How to Optimize Your Code to Run Faster
Tuesday, November 13th, 2007JavaScript and the web industry go hand-in-hand. It was booming
during the dot-boom, and it took somewhat of a backseat position during the dot-crash. (If you knew how to create rollovers in 1997, or DHTML apps in 1998, there was no shortage of work for you.)
The last couple of years has certainly seen JavaScript take center stage again on the wings of overused buzzwords such as AJAX and JSON, but–with the emergence of Web 3.0–getting your code leaner and meaner will mean you can run more robust applications on a greater variety of emerging platforms.
That, too, was the goal of Web 2.0, but–dareisay–part of the goal of Web 3.0 is what Java failed to deliver ten years ago: write once, read everywhere. (Can I script my fridge to tell me when it’s out of juice yet?)
Regardless if you’re like me (cough, skeptical), you still have to think of processing large swathes of data, regardless of platform. Mobile devices and desktops are the new web browser, and the unknown platform of tomorrow is the platform of today. Developing a successful JavaScript engine means optimizing it to run as fast as possible, quickly delivering what the client is requesting: your content.
In no particular order, here are 11 improvements you can make to optimize your scripts to run faster:
- Less is more–minify your code
- Ask for things less–make fewer HTTP requests
- Take only what you need with you–only include the code you need
- Down with DOM–traverse trees as little as possible
- Up with DHTML–faster than the Document Object Model
- Don’t concat–join!
- Code in JSON–data storage at lower costs
- Clean up your garbage–destroy data, free memory
- Don’t let me keep you waiting–how scripts slow page load, and what you can do about it
- Let me tell you something–indicate to users what you’re doing
- Show your site first–load your scripts last
It’s obvious (or, should be) that less code runs faster, but it bears repeating: minify your code.
One of my early JavaScript gigs was to minify about 1000 lines of code to meet a requirement of 40k. The original file was over 90k. Changing all name-spaces (variable names, function names, etc.) to 1-2 characters, and removing all \n, \r and \t from the file brought it down to 37k.
Those numbers may be negligible now that we’re no longer 56kbps optimizing for 33kbps, but getting your code to run 2.5 times faster is still 2.5 faster, and your client could conceivably be a mobile device that’s still chugging-away at blistering, modem-like speeds.
There are some server-side utilities that can aid you in minifying your code. If you run PHP, you may want to consider the JSMin Library.
Seriously. Stop being so selfish. You’re always asking for things. Like files.
Each time you request a file from the server–be it an image, a CSS file, or JS document–the server has to make sure it’s there. Which means–even if the file is cached–an HTTP request-response needs to take place before the client receives the header telling it that “this file has not changed,” and “it’s okay to use the cached version.”
This obviously takes time.
So–in terms of download time–the more JS includes you have, the slower your page will be. It’s better to place all your JavaScript in one file; even if that file is rather large. The browser makes just one HTTP request to download it, and simply moves on.
3. Take only what you need with you
JavaScript files are often bloated with stuff that isn’t needed at the time–and especially if you’re using a framework like Prototype, jQuery or Ext JS. Those frameworks are neat, and provide a lot of cool features, but often come with components you won’t need for your app, so–even if you are using a framework–try to create custom builds each time you use them, such that you only take what you need with you.
An alternative to loading everything all at once, or creating one huge master file, is to load JS documents on demand:
js_include:function(src) {
if(document.createElement) {
js=document.createElement('script');
js.setAttribute('type','text/javascript');
js.setAttribute('src',src);
document.getElementsByTagName('head')[0].appendChild(js);
}
}
So–for example–say you happen to have a name-space that contains all your forms-processing logic; you can test to see if it exists, and call its library if not:
if(!window.MyFormsObject) {
js_include('/js/lib/myFormsLib.js');
}
Web 2.0 saw the popularity of the Document Object Model (DOM), and the HTML document as an XML tree. Parents have children, children have siblings–what a lovely, nuclear family we have here.
From a JavaScript perspective, however, traversing the DOM takes time and resources. This especially becomes an issue if you’re developing widgets for unknown environments. If you simply must traverse the DOM to getElementsByClassName or getElementsByTagName, do so within your pre-defined name-space.
For example, let’s say your app exists within a name-space called myUniqueAppName, and you want to read or target all a elements within that app. Instead of traversing the tree for the entire document–which can potentially slog through a ton of meaningless nodes (especially if your widget is, say, on a social networking site)–drill down from your name-space:
var myNameSpace=document.getElementsById('myUniqueAppName');
var myAnchorTags=myNameSpace.getElementsByTagName('a');
for(var i=0; i<myAnchorTags.length; i++) {
// do something
}
If you read my post on centralizing DOM accessibility, then you should be familiar with more secure methods of normalization:
var dom = {
getElementById:function(id, tag) {
if(document.getElementById && document.getElementById(id)) {
return document.getElementById(id);
}
if(document.layers && document.layers[id]) {
return document.layers[id];
}
if(document.all && document.all[id]) {
return document.all[id];
}
if(this.createElement) {
tag=(tag)? tag : 'div';
el=this.createElement(tag);
el.setAttribute('id', id);
this.getElementsByTagName('body')[0].appendChild(el);
return el;
}
return null;
},
getElementsByTagName:function(tag, el) {
var el=(el)? el : document;
if(el.getElementsByTagName) {
return el.getElementsByTagName(tag);
}
return null;
}
};
Which can help centralize your JS such that:
var myAnchorTags=dom.getElementsByTagName('a', dom.getElementById('myUniqueAppName'));
It’s always better to reference elements directly using document.getElementById, but if you have to: traversing branches to reach a twig is faster than traversing the entire tree.
Any meaningful JavaScript application dynamically builds objects, elements and strings. Using the DOM to do so may have a certain “cool” factor:
function getImage(src, width, height, alt, toElement) {
var myIMG=document.createElement('img');
myIMG.setAttribute('src', src);
myIMG.setAttribute('width', width);
myIMG.setAttribute('height', height);
myIMG.setAttribute('alt', alt);
toElement.appendChild(myIMG);
}
But the DHTML solution simply runs faster:
function getImage(src, width, height, alt, toElement) {
toElementtoElement.innerHTML='<img src="'+src+'" width="'+width+'"' height="'+height+'" alt="'+alt+'" />';
}
And–in this case–also uses less code.
When you’re dynamically building strings, don’t use concatination to build them (as I did in the previous example). String concatination can be memory-intensive–it’s much better to store your data as array elements:
var myIMG=new Array('<img src="', src, '" width="', width, '"' height="', height, '" alt="', alt, '" />');
If you need to add items to it later, you can use Array.push():
myIMG.push('<br /><strong>', caption, '</strong>');
Then, when it’s time to publish to screen, you can simply:
myElement.innerHTML=myIMG.join('');
Array.join() simply joins all array elements together into one string. Since its a native function, it concatinates elements into strings faster than you can do so manually, which makes your script run faster.
JavaScript Object Notation, or JSON, is a short-hand form of data-storage in JavaScript. In other words, you can store objects, arrays, strings, numbers and boolean values using less code.
As such, it costs less KB in terms of download time, and runs faster. The array in the previous example looks like this in JSON:
var myIMG=['<img src="', src, '" width="', width, '"' height="', height, '" alt="', alt, '" />'];
(You can read more about JSON at json.org.)
Excuse me, but I believe you left your array lying around. Do you expect me to clean that up, or were you planning on getting around to it?
Consider the last few examples. By the end of example 6, you would’ve printed your HTML code to screen, and your job would’ve been complete.
But, is it? What about the array–where did it go?
The truth is: it hasn’t gone anywhere. The contents of your array may have been printed to screen, but the array is still sitting in memory, watching its nails grow. This means the browser is storing that data for no reason whatsoever, slowing down any subsequent operations.
Therefore, it’s always better to eliminate the contents of your array after you’re done with it:
myElement.innerHTML=myIMG.join('');
myIMG.length=0;
By setting the Array.length property to 0, the array effectively loses memory of its contents, and frees up the browser to run that much faster.
If you’re like me, and like to normalize behavior like this, you can extend the Array object to perform this operation:
Array.prototype.destroy=function() {
this.length=0;
return this;
}
In action, this would look like:
myElement.innerHTML=myIMG.join('');
myIMG.destroy();
You may also have a String or Object that no longer contains any meaningfull data:
Object.prototype.destroy=function() {
this.length=0;
return this;
}
This especially becomes important when you’re parsing objects that contain a lot of data. For example, let’s say you have an AJAX application returns a JSON object containing thousands of entries:
var myJSON=json.parse(ajax.response);
Once you’ve taken that data, dressed it up to look all pretty, and sent it out to party, you will definitely want to discard it:
var myJSON=json.parse(ajax.response);
// do something fun
myJSON.destroy();
Less data the browser stores, the faster it runs.
9. Don’t let me keep you waiting
Whenever the browser executes one of your scripts, it patiently waits with its hands in its pockets until your script is done. In other words, it stops loading the rest of the page while your script is doing its thing.
This can be negligible if your script does little, but will very directly effect the download time for your entire document if you’re running a lot of computations, or using HTTP to fetch data.
Since the browser is kind enough to wait for your script to run, you should be nice enough to tell the browser if your script may take time to run. For example, let’s say you’re embedding a Flash widget somewhere at the top of your document, and you’re using JavaScript to draw it (which should be standard procedure these days):
var myFlashObject=new FlashObject("myFlashFile.swf");
myFlashObject.param("quality","high");
myFlashObject.draw();
So far, so good. But, Flash can take time to draw, and if your app has to load a lot of assets, your page will just h-a-n-g there until it’s done.
You can, however, tell the browser to stop waiting for your script to finish by using setTimeout():
var myFlashObject=new FlashObject("myFlashFile.swf");
myFlashObject.param("quality","high");
setTimeout('myFlashObject.draw()', 0);
This tells the client to wait exactly 0 milliseconds before executing your function (myFlashObject.draw()).
The fact that it’s zero time spent is almost irrelevant–that you’re telling the browser to wait at all wakes it up from its patient slumber, and sends it back to retrieving the rest of your document; leaving your script to continue running in the background.
This speeds up both download time and generates better user-experience.
The first parameter of setTimeout() is a string, by default, so if you’re passing parameters to your routine, you have to rely on concatenation to pass your data:
setTimeout('myFlashObject.draw('+myParam+')', 0);
Rebuilding your function by way of concatenation can tack some extra time onto your script, so if you need to pass parameters to your function, you may find it faster to define an inline function:
setTimeout(function() { myFlashObject.draw(myParam); }, 0);
This way, you don’t keep the browser waiting for you when it can otherwise be serving content to the client.
People like seeing reactions to actions they take. If I press a button for the elevator to come pick me up, and the button doesn’t light up, I start pressing it repeatedly, thinking “it’s not working.”
The same is true with application development–if not more so. A user-initiated action may take time to load; especially if your script is making a round-trip to the server.
Part of speeding up your application is giving users the impression that things are going faster than they are. On the CSS side of things, this may mean assigning background colors to elements whose pixel-majority contains that color (HEX/RGB colors require zero HTTP requests, so they draw immediately); on the JavaScript side, this means providing visual cues as to what it is you’re actually doing.
Simple text messages like “Loading…” or “Processing…” suffice, but small animations offer a light-weight solutions to indicate to the user that time is actively being spent.
During the boom days, most developers got into the habit of including their scripts in the <head> of their documents.
While this was typically done to pre-load elements like images for effects like rollovers, this technique has gained widespread acceptance as common practice.
The downfall here is that the browser is busy processing logic, and/or making HTTP calls, before showing the user anything about the page they requested. While your overall download speed may or may not differ in the end, the longer it takes to display any content to the user, the “longer” your page load is.
Therefore, it is much more optimal to load your scripts towards the bottom of your document; or based on certain events (onload, onclick, etc.); or just before you absolutely need them.
Your client is your user–and users want to see things first, do things second–so the only data you should include in the <head> of your document are CSS and META data.