For a basic JavaScript app, you probably don't need to worry about performance. But if you're writing a non-trivial JavaScript Web app, it might be an issue. We've got four simple tricks to help squeeze a little extra speed out of your JavaScript.
Got a quick-and-dirty Web application? Then a quick-and-dirty script will probably be fine. Small apps don’t strain resources, and so they generally execute quickly even if they’re not particularly well written. But if the app isn’t quick and dirty, then dirty scripting means the app certainly won’t be quick. Your JavaScript is probably fine, whether the app is simple or complex. But by using these four simple tricks, you can make it better still.
Tip #1: Cache your JavaScript if it is used by multiple pagesIf the same script code is going to be used in multiple pages, you can make the app more efficient by caching the code. By caching it in the browser, you pay a modest price up front by requiring the browser to download the code the first time. But you’ll recoup it many times over through the decreased load time.It’s easy to do. Tag the script in your app with
, and specify the file containing the script with the src attribute:
Once the browser pulls in the code, it will appear in the app just as if it had been hard-coded in. In addition to being efficient across multiple pages, it’s useful across multiple apps and multiple servers: Since the URL of the script code can reference it anywhere, on any server, you can import JavaScript code into one app or many from remote servers, if you like. You can even (if you ever had a good reason to do it) piece together an app with JavaScript code from multiple servers, in real time.
Tip #2: Accumulate HTML in string variablesWhen you write a large amount of content to a page, you may be building the page content element by element as it loads, using document.write( ). This works fine, but cranking out HTML this way is I/O-intensive.An alternative is to confine yourself to a single use of document.write( ). Instead of generating the HTML in pieces, assemble it in a string. When it’s all loaded into a string variable, use document.write( ) once to put it to the page.
Tip #3: Do large array lookups as string searchesPlowing through an array is always a cycle drain. Why? Because in addition to the repetitive evaluation, you have the overhead of the control structure you’ve set up to loop through the array. You’re better off using the built-in mechanics.An array in JavaScript is also an object in JavaScript. Great news for you: Because you know the keyfield(s) for the array you’re searching, and the relative position of the field holding the data you’re searching for, you can search the array as an object, by first defining as an object property the unique (keyfield) portion of each array row. If the actual data found in this keyfield isn’t necessarily unique, then hedge your bet by combining it with some other field that will make it so. Then you can build a temp table once, at page load, that marks the relative positions of your unique entries, and jump straight to it as a reference point to grab the data. Overall, you’ll net a significant savings in processing cycles.
Tip #4: Avoid inefficient commands in recursive codeAt face value, this tip is common sense that pretty much goes without saying. But are you aware of what JavaScript functions are inefficient? Some of them might surprise you. For instance, the Document Object Model’s various methods and functions are marvelous efficiency tools, but can gum up your application considerably if used in the wrong place.If you’re doing a tree search, for instance, to retrieve an element in a child node, you should avoid using a DOM method itself (to identify the element) in the loop-control logic; the overhead you’ll suffer is a killer. Why? Because when a method is invoked, it is evaluated, and that costs cycles and is completely unnecessary. Instead, invoke the method once and load the ID of the element you’re seeking into a local variable.Another killer function is eval( ). It’s useful for converting a text object ID into an actual object reference. The problem is that it’s a cycle hog, and it’s most often used to do wholesale mass references to page elements when there are lots and lots of them and their names really aren’t important. But don’t go there; you’ll bring your app to its knees.Instead, try using DOM’s native features for identifying elements—that is, instead of creating object referents by assigning arbitrary names and making them real with eval( ), go with the names that already exist (in DOM; which DOM expression you’d use for this depends on the type of element you’re trying to name). Note that this use of DOM document expressions differs from the example above. Each reference is distinctly useful, creating an authentic object reference, as opposed to repetitively invoking a method when it needs to be invoked only once.
Got a quick-and-dirty Web application? Then a quick-and-dirty script will probably be fine. Small apps don’t strain resources, and so they generally execute quickly even if they’re not particularly well written. But if the app isn’t quick and dirty, then dirty scripting means the app certainly won’t be quick. Your JavaScript is probably fine, whether the app is simple or complex. But by using these four simple tricks, you can make it better still.
Tip #1: Cache your JavaScript if it is used by multiple pagesIf the same script code is going to be used in multiple pages, you can make the app more efficient by caching the code. By caching it in the browser, you pay a modest price up front by requiring the browser to download the code the first time. But you’ll recoup it many times over through the decreased load time.It’s easy to do. Tag the script in your app with
, and specify the file containing the script with the src attribute:
Once the browser pulls in the code, it will appear in the app just as if it had been hard-coded in. In addition to being efficient across multiple pages, it’s useful across multiple apps and multiple servers: Since the URL of the script code can reference it anywhere, on any server, you can import JavaScript code into one app or many from remote servers, if you like. You can even (if you ever had a good reason to do it) piece together an app with JavaScript code from multiple servers, in real time.
Tip #2: Accumulate HTML in string variablesWhen you write a large amount of content to a page, you may be building the page content element by element as it loads, using document.write( ). This works fine, but cranking out HTML this way is I/O-intensive.An alternative is to confine yourself to a single use of document.write( ). Instead of generating the HTML in pieces, assemble it in a string. When it’s all loaded into a string variable, use document.write( ) once to put it to the page.
Tip #3: Do large array lookups as string searchesPlowing through an array is always a cycle drain. Why? Because in addition to the repetitive evaluation, you have the overhead of the control structure you’ve set up to loop through the array. You’re better off using the built-in mechanics.An array in JavaScript is also an object in JavaScript. Great news for you: Because you know the keyfield(s) for the array you’re searching, and the relative position of the field holding the data you’re searching for, you can search the array as an object, by first defining as an object property the unique (keyfield) portion of each array row. If the actual data found in this keyfield isn’t necessarily unique, then hedge your bet by combining it with some other field that will make it so. Then you can build a temp table once, at page load, that marks the relative positions of your unique entries, and jump straight to it as a reference point to grab the data. Overall, you’ll net a significant savings in processing cycles.
Tip #4: Avoid inefficient commands in recursive codeAt face value, this tip is common sense that pretty much goes without saying. But are you aware of what JavaScript functions are inefficient? Some of them might surprise you. For instance, the Document Object Model’s various methods and functions are marvelous efficiency tools, but can gum up your application considerably if used in the wrong place.If you’re doing a tree search, for instance, to retrieve an element in a child node, you should avoid using a DOM method itself (to identify the element) in the loop-control logic; the overhead you’ll suffer is a killer. Why? Because when a method is invoked, it is evaluated, and that costs cycles and is completely unnecessary. Instead, invoke the method once and load the ID of the element you’re seeking into a local variable.Another killer function is eval( ). It’s useful for converting a text object ID into an actual object reference. The problem is that it’s a cycle hog, and it’s most often used to do wholesale mass references to page elements when there are lots and lots of them and their names really aren’t important. But don’t go there; you’ll bring your app to its knees.Instead, try using DOM’s native features for identifying elements—that is, instead of creating object referents by assigning arbitrary names and making them real with eval( ), go with the names that already exist (in DOM; which DOM expression you’d use for this depends on the type of element you’re trying to name). Note that this use of DOM document expressions differs from the example above. Each reference is distinctly useful, creating an authentic object reference, as opposed to repetitively invoking a method when it needs to be invoked only once.
No comments:
Post a Comment