Web Client Performance

Web Client performance

Herea Adrian

adrian.herea@infoiasi.ro

The current paper tries to put together information about the ways of
improvement of speed on web client. We will see which are the tips of yslow
how we follow them and what we should do or not. We will also see how we
could write better JavaScript code which could improve the performance.

2 Herea Adrian

Prologue

The Pareto Principle

Economist Vilfredo Pareto found in 1897 that about 80 percent of Italy's wealth
was owned by about 20 percent of the population. This has become the 80/20 rule or
the Pareto principle, which is often applied to a variety of disciplines. Although some
say it should be adjusted to a 90/10 rule, this rule of thumb applies to everything from
employee productivity and quality control to programming.

Barry Boehm found that 20 percent of a program consumes 80 percent of the
execution time. He also found that 20 percent of software modules are responsible for
80 percent of the errors. Donald Knuth found that more than 50 percent of a program's
run time is usually due to less than 4 percent of the code. Clearly, a small portion of
code accounts for the majority of program execution time.

The importance of performance

500 ms slower = 20% drop in traffic (Google)
400 ms slower = 5-9% drop in full-page traffic* (Yahoo!)
100 ms slower = 1% drop in sales (Amazon)

Users leaving before the page finishes loading

Tips for a fast web page inspired by YSlow 3

Tips for a fast web page inspired by YSlow

YSlow by Yahoo! is little plugin for Firefox and Firebug. It looks at a page and
uses Yahoo!‟s Best Practices for Speeding Up Your Web Site to tell you how to make
the page load faster. At least that is the idea behind it. In practice, however, not all of
its suggestions are useful or even meaningful.

1. Make Fewer HTTP Requests

If the browser has to make fewer requests, it can display your page faster.
There are 3 reasons for this. One is every HTTP request has a small amount of
network overhead, and the more requests you remove, the less overall network traffic.
The second reason is browsers have a limit to the # of HTTP requests they can
make to a webserver (or hostname, specifically). Older browsers were limited to 2.
Some newer browsers have upped that limit to 6 or 8, but they still have a limit.
Therefore when a browser has reached its limit, it has to wait for requests to finish
before starting up new ones. So the more requests necessary, the more queuing will
occur.
The third reason is specific to JavaScript in that browsers will only download and
execute 1 JavaScript file at a time. This is done because JavaScript can modify the
DOM, redirect the page or do any number of things that may affect what resources
need to be downloaded. So even if a browser can download 8 requests in parallel,
JavaScript files will still be download sequentially. (There are efforts to improve this
issue in Webkit and Gecko.)
That fewer requests leads to faster display is generally true, although some types of
pages require more images and such as part of their content. To account for this,
YSlow only looks at three types of request: Javascript files, style sheet files, and
images references in style sheets (CSS images). For each one of these, if you have too
many of them, your score starts to drop. The limits are 3 scripts, 2 style sheets, and 6
CSS images.
Following their suggestions, although the CSS images one may be too strict, can
really improve the performance.

2. Use a Content Delivery Network

Content delivery networks let you spread your content out on a geographically
dispersed network of servers so it can be delivered to your users more quickly. This is
especially good to do for components of your page such as images and scripts, rather
than the core content that you may need to serve dynamically.
YSlow restricts its attention to scripts, images, CSS images, style sheets, and Flash
objects. For each of these, it matches the URL against a list of known CDN URL

4 Herea Adrian

patterns. You can also add your own CDN patterns, if you need to. Every one of those
files that doesn‟t match a CDN costs you points.
This advice can be ignored because almost all sites do not get enough traffic to
justify it, but CDNs are too expensive for most webmasters.

3. Add an Expires Header

Save requests for your return visitors by letting them know how long page
elements are good.
Expires headers are a type of header that tells the browser when an asset „expires‟
from its cache. When you set it to years in the future, a browser will cache it and
never ask the website again for it.
Expires headers look like this:

Expires: Thu, 15 Apr 2020 20:00:00 GMT

The assets you want to set expires headers on are things that don‟t change much.
Like images, CSS and JavaScript. I know, CSS & JavaScript might change every
week or two and this can result in your users never seeing new content. The way
around this is to change the filename of your assets whenever you update them. This
can be done manually or with a build script of some sort.
You can set expires headers in Apache by adding this to your httpd.conf or
.htaccess file:

<FilesMatch
".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">

Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"

</FilesMatch>

Again YSlow turns its eye to scripts, images, CSS images, style sheets, and
Flash objects. If any don‟t have an expires header that lets them live at least 48 hours
(or a cache-control header that does the same thing), down goes your score.
This is the single biggest part of your YSlow score and for good reason. Expires
headers really do help speed things up and they are easy to add. In Apache, it is as
simple as adding a couple of mod_expires directives to your .htaccess file.

4. Gzip Components

If you compress your content it will get your users faster.


Images are generally already compressed by virtue of their file formats (JPEG,
GIF, etc.), so this time YSlow focuses on everything else. If any of them aren‟t
compressed, you lose points fast. Even one infraction and you have lost your A. Miss
four and you get an F.
Computers are fast and networks are slow. Compressing your files just makes
sense and is easy to do. Apache‟s mod_deflate (or mod_gzip for the 1.3 crowd) lets
you do it with a few small changes to your .htaccess file.

5. Put CSS at the Top

Give your browser all the style information upfront so it can get the layout right the
first time.
Every style sheet used that is not mentioned in the header costs you a letter grade.
Do what you can. It is a good idea, but is not always possible if you are including
dynamic content from other sites, such as widgets, ads, etc. that include their own
CSS.

6. Move Scripts to the Bottom

Let the browser finish laying out your page before you start running all sorts of
dynamic scripts.
Browsers only download 1 JavaScript file at a time? Well, they also block
rendering of any content after them in the DOM. So when your JavaScript is
referenced at the top of the page, like most webpages do, it blocks the rest of the page.
The solution? Move them below all your content!
The same as #5, except every script used that is mentioned in the header costs you
a letter grade.
On the one hand, they do have a point about how the page will load. On the other
hand, the scripts will download faster if they are referenced in the header. This is what
onLoad is for. And many widgets and ads have to be included inline so you can‟t win
anyway. Do what you want.

7. Avoid CSS Expressions

Don‟t make the browser work harder than necessary for your style sheets.
You start this one with barely an A and work down from there. Every expression
costs you just two points, so you can get away with a few and still get a B.
You should avoid CSS expressions, although not necessarily for speed reasons.
You should avoid them because they are a nonstandard Microsoft “extension” that
will do nothing but cause you headaches as you try to make your site work cross-
browser. Anyone who gets less than an A here deserves their headaches.

6 Herea Adrian

8. Make JavaScript and CSS External

Moving style sheets and scripts out of your (X)HTML will allow them to be
cached by browsers for subsequent page views on your site.
The code for this test is a stub that always gives you an “n/a” with a note saying
this it only makes sense for home pages.
Make them external if they are used on multiple pages of your site. It will help on
subsequent pages. On the other hand, if stuff is specific to one page, feel free to inline
with immunity.

9. Reduce DNS Lookups

The fewer host names a browser has to resolve, the faster it can load your page.
YSlow counts up all the host names for all the components. Anything past two will
cost you 5 points. So, four or fewer is an A, five of six a B, and so on.
Most of the time if you have multiple host names being used, it is because you are
including widgets or ads from somewhere else or you are using a CDN (see #2) to
speed things up. Nice catch-22 there. Try to minimize the number of hosts, but don‟t
sweat it too much for things like ads and CDNs, as your users‟ browsers may already
have resolved those hosts.

10. Minify JavaScript

While compressing Javascripts saves bandwidth and time (see #4), it turns out that
compression works out even better on Javascript that has been “minified.”
YSlow does a clever thing here and just looks for whitespace and comments in
your JS files. If it finds them, the file is definitely not minified. You lose 10 points per
non-minified file, so one offense is still an A, but you drop a letter grade for each
additional infraction.
Recommendation is to do it, once you have your scripts debugged. Debugging
minified code is self-flagellation. The difference between compression on a minified
script and a non-minified one is small, but measurable, so it is probably worth the
one-time effort. Compressor Rater can help you find the best compression overall for
your Javascript.

11. Avoid Redirects

Bouncing between different URLs causes more requests and more time, so avoid
them.


YSlow looks at each component to check for redirects. As with non-minified JS
files, you lose 10 points per redirect. One redirect is okay, but any past that and your
grade drops fast.
Redirects are a useful tool, and are sometime quite useful, but they can be
overused. Avoid them if you don‟t have a good reason to use them.

12. Remove Duplicate Scripts

Don‟t load twice what you can load once.
Any JS file loaded more than once costs you five points, which means you can still
get an A with three duplicates.
Do your best. Duplicated scripts are rarely intentional, but they do happen all the
time. Every page that has moer than one AdSense block on it is guilty, which is
probably why YSlow cuts you some slack.

13. Configure ETags

ETags help reduce duplicate requests, so using them is good.
YSlow doesn‟t just look for ETag headers, but looks for ones that it feels are
valid. This means that it expects any application-generated ETag headers to match
those generated by your web server. As with several of the other tests, YSlow only
looks at scripts, images, CSS images, style sheets, and Flash objects.
Don‟t bother. ETags are helpful, but Expires headers accomplish much of the same
job. Furthermore, YSlow‟s implementation is, in my opinion, broken. There is
nothing in the HTTP specification that requires a specific format for ETags. An web
application should be able to generate whatever form ETag it wants provided it can
use it to determine if the content of the page has changed. A commonly used
technique is to use an MD5 of the content, but YSlow deems this unacceptable.

8 Herea Adrian

Optimizing JavaScript for Execution Speed

As our JavaScript applications get larger and ever more sophisticated, the need for
efficient scripting becomes increasingly important and hard to bypass. Back in the
days when all that JavaScript could do was change your document's background
color, or validate a simple form, abuse in terms of efficiency in our codes was
common, with the browser not having a problem with it at all. Now, especially with
the language's marriage with DHTML, in turn, the ability to create almost full blown
applications, efficiency is no longer something we can sweep under the rug, and
forget about.
JavaScript can benefit from many of the same speed-optimization techniques that
are used in other languages, like C1,2 and Java. Algorithms and data structures,
caching frequently used values, loop unrolling and hoisting, removing tail recursion,
and strength-reduction techniques all have a place in your JavaScript optimization
toolbox. However, how you interact with the Document Object Model (DOM) in
large part determines how efficiently your code executes.
Unlike other programming languages, JavaScript manipulates web pages through a
relatively sluggish API, the DOM. Interacting with the DOM is almost always more
expensive than straight computations. After choosing the right algorithm and data
structure and refactoring, your next consideration should be minimizing DOM
interaction and I/O operations.
With most programming languages, you can trade space for time complexity and
vice versa. But on the web, Java Scripts must be downloaded. Unlike desktop
applications where you can trade another kilobyte or two for speed, with JavaScript
you have to balance execution speed versus file size.
Unlike C, with its optimizing compilers that increase execution speed and decrease
file size, JavaScript is an interpreted language that usually is run over a network
connection (unless you count Netscape's Rhino, which can compile and optimize
JavaScript into Java byte code for embedded applications). This makes JavaScript
relatively slow compared to compiled languages. However, most scripts are usually so
small and fast that users won't notice any speed degradation.
Many would agree that it's just a matter of time now before JavaScript eventually
graduates to become a full blown language like C or Java. Practicing responsible and
efficient coding now can save you a lot of work in the future

Design Levels

A hierarchy of optimization levels exists for JavaScript, what Bentley and others
call design levels.6 First comes the global changes like using the right algorithms and
data structures that can speed up your code by orders of magnitude. Next comes
refactoring that restructures code in a disciplined way into a simpler, more efficient
form7). Then comes minimizing DOM interaction and I/O or HTTP requests. Finally,
if performance is still a problem, use local optimizations like caching frequently used
values to save on recalculation costs. Here is a summary of the optimization process:

Optimizing JavaScript for Execution Speed 9

Choose the right algorithm and data structure.

1. Refactor to simplify code.

2. Minimize DOM and I/O interaction.

3. Use local optimizations last.

When optimizing your code, start at the highest level and work your way down until
the code executes fast enough. For maximum speed, work at multiple levels.

Measure Your Changes

Measurement is a key part of the optimization process. Use the simplest algorithms
and data structures you can, and measure your code's performance to see whether you
need to make any changes. Use timing commands or profilers to locate any
bottlenecks. Optimize these hot spots one at a time, and measure any improvement.
You can use the date object to time individual snippets:
<script type="text/javascript">

function DoBench(x){

var startTime,endTime,gORl='local';

if(x==1){

startTime=new Date().getTime();

Bench1();

endTime=new Date().getTime();

}else{

gORl='global';

startTime=new Date().getTime();

Bench2();

endTime=new Date().getTime();

}

10 Herea Adrian

alert('Elapsed time using '+gORl+' variable:
'+((endTime-startTime)/1000)+' seconds.');

}

...

</script>
This is useful when comparing one technique to another. But for larger projects,
only a profiler will do. Mozilla.org includes the Venkman profiler in the Mozilla
browser distribution to help optimize your JavaScript.

Algorithms and Data Structures

As we learn in computer science classes, global optimizations (such as algorithm
and data structure choices) determine in large part the overall performance of our
programs. For larger values of "n," or the number of input elements, the complexity of
running time can dominate any local optimization concerns. This complexity is
expressed in O-notation, where complexity or "order" is expressed as a function of n.
Table 10.1 shows some examples.

Notation Name Example
O(1) constant array index, simple statements
O(logn) logarithmic binary search
O(n) linear string comparison, sequential search
O(nlogn) nlogn quicksort and heapsort
O(n2) quadratic simple selection and insertion sorting methods (two loops)
O(n3) cubic matrix multiplication of nxn matrices
O(2n) exponential set partitioning (traveling salesman)

Array access or simple statements are constant-time operations, or O(1). Well-
crafted quicksorts run in nlogn time or O(nlogn). Two nested for loops take on the
order of nxn or O(n2) time. For low values of n, choose simple data structures and
algorithms. As your data grows, use lower-order algorithms and data structures that
will scale for larger inputs.
Use built-in functions whenever possible (like the Math object), because these are
generally faster than custom replacements. For critical inner loops, measure your
changes because performance can vary among different browsers.


Refactor to Simplify Code

Refactoring is the art of reworking your code to a more simplified or efficient form
in a disciplined way. Refactoring is an iterative process:
1. Write correct, well-commented code that works.
2. Get it debugged.
3. Streamline and refine by refactoring the code to replace complex sections with
shorter, more efficient code.
4. Mix well, and repeat.
Refactoring clarifies, refines, and in many cases speeds up your code. Here's a
simple example that replaces an assignment with an initialization. So instead of this:

function foo() {

var i;

// ....

i = 5;

}

Do this:

function foo() {

var i = 5;

// ....

}

Minimize DOM Interaction and I/O

Interacting with the DOM is significantly more complicated than arithmetic
computations, which makes it slower. When the JavaScript interpreter encounters a
scoped object, the engine resolves the reference by looking up the first object in the
chain and working its way through the next object until it finds the referenced
property. To maximize object resolution speed, minimize the scope chain of objects.

12 Herea Adrian

Each node reference within an element's scope chain means more lookups for the
browser. Keep in mind that there are exceptions, like the window object, which is
faster to fully reference. So instead of this:

var link = location.href;

Do this:

var link = window.location.href;

Minimize Object and Property Lookups

Object-oriented techniques encourage encapsulation by tacking sub-nodes and
methods onto objects. However, object-property lookups are slow, especially if there
is an evaluation. So instead of this:

for(var i = 0; i < 1000; i++)

a.b.c.d(i);

Do this:

var e = a.b.c.d;

for(var i = 0; i < 1000; i++)

e(i);

Reduce the number of dots (object.property) and brackets
(object["property"]) in your program by caching frequently used objects and
properties. Nested properties are the worst offenders (object. property.
property. property).
Here is an example of minimizing lookups in a loop. Instead of this:

for (i=0; i<someArrayOrObject.length; i++)

Do this:

for (i=0, var n=someArrayOrObject.length; i<n; i++)


Also, accessing a named property or object requires a lookup. When possible, refer
to the object or property directly by using an index into an object array. So instead of
this:
var form = document.f2; // refer to form by name

Do this:

var form = document.forms[1]; // refer to form by
position

Shorten Scope Chains

Every time a function executes, JavaScript creates an execution context that defines
its own little world for local variables. Each execution context has an associated scope
chain object that defines the object's place in the document's hierarchy. The scope
chain lists the objects within the global namespace that are searched when evaluating
an object or property. Each time a JavaScript program begins executing, certain built-
in objects are created.
The global object lists the properties (global variables) and predefined values and
functions (Math, parseInt(), etc.) that are available to all JavaScript programs.
Each time a function executes, a temporary call object is created. The function's
arguments and variables are stored as properties of its call object. Local variables are
properties of the call object.
Within each call object is the calling scope. Each set of brackets recursively
defines a new child of that scope. When JavaScript looks up a variable (called
variable name resolution), the JavaScript interpreter looks first in the local scope,
then in its parent, then in the parent of that scope, and so on until it hits the global
scope. In other words, JavaScript looks at the first item in the scope chain, and if it
doesn't find the variable, it bubbles up the chain until it hits the global object.
That's why global scopes are slow. They are worst-case scenarios for object
lookups.
During execution, only with statements and catch clauses affect the scope
chain.

Avoid with Statements

The with statement extends the scope chain temporarily with a computed object,
executes a statement with this longer scope chain, and then restores the original scope
chain. This can save you typing time, but cost you execution time. Each additional
child node you refer to means more work for the browser in scanning the global
namespace of your document. So instead of this:

with (document.formname) {

14 Herea Adrian

field1.value = "one";

field2.value = "two";...

}

Do this:

var form = document.formname;

form.field1.value = "one";

form.field2.value = "two;

Cache the object or property reference instead of using with, and use this variable
for repeated references. with also has been deprecated, so it is best avoided.

Add Complex Subtrees Offline

When you are adding complex content to your page (like a table), you will find it is
faster to build your DOM node and all its sub-nodes offline before adding it to the
document. So instead of this (see Code Sample 1):

Code Sample 1 Adding Complex Subtrees Online

var tableEl, rowEl, cellEl;

var numRows = 10;

var numCells = 5;

tableEl = document.createElement("TABLE");

tableEl = document.body.appendChild(tableEl);

for (i = 0; i < numRows; i++) {

rowEl = document.createElement("TR");

for (j = 0; j < numCells;j++) {

cellEl = document.createElement("TD");


cellEl.appendChild(document.createTextNode("[row
"+i+" cell "+j+ "]"));

rowEl.appendChild(cellEl);

}

tableEl.appendChild(rowEl);

}

Do this (see Code Sample2):
Code Sample 2 Adding Complex Subtrees Offline

var tableEl, rowEl, cellEl;

var numRows = 10;

var numCells = 5;

tableEl = document.createElement("TABLE");

for (i = 0; i < numRows; i++) {

rowEl = document.createElement("TR");

for (j = 0; j < numCells;j++) {

cellEl = document.createElement("TD");

cellEl.appendChild(document.createTextNode("[row "
+i+ " cell "+j+"]"));

rowEl.appendChild(cellEl);

}

tableEl.appendChild(rowEl);

}

document.body.appendChild(tableEl);

Code Sample 1 adds the table object to the page immediately after it is created and
adds the rows afterward. This runs much slower because the browser must update the

16 Herea Adrian

page display every time a new row is added. Code Sample 2 runs faster because it
adds the resulting table object last, via document.body.appendChild().

Edit Subtrees Offline

In a similar fashion, when you are manipulating subtrees of a document, first
remove the subtree, modify it, and then re-add it. DOM manipulation causes large
parts of the tree to recalculate the display, slowing things down. Also,
createElement() is slow compared to cloneNode(). When possible, create a
template subtree, and then clone it to create others, only changing what is necessary.
Let's combine these two optimizations into one example. So instead of this (see Code
Sample 3):

Code Sample 3 Editing Subtrees Online

var ul = document.getElementById("myUL");

for (var i = 0; i < 200; i++) {

ul.appendChild(document.createElement("LI"));

}

Do this (see Code Sample 4):
Code Sample 4 Editing Subtrees Offline

var ul = document.getElementById("myUL");

var li = document.createElement("LI");

var parent = ul.parentNode;

parent.removeChild(ul);

for (var i = 0; i < 200; i++) {

ul.appendChild(li.cloneNode(true));

}

parent.appendChild(ul);


By editing your subtrees offline, you'll realize significant performance gains. The
more complex the source document, the better the gain. Substituting cloneNode
instead of createElement adds an extra boost.

Concatenate Long Strings

By the same token, avoid multiple document.writes in favor of one
document.write of a concatenated string. So instead of this:

document.write(' string 1');




Do this:

var txt = ' string 1'+

' string 2'+

' string 3'+

' string 4';

document.write(txt);

Access NodeLists Directly

NodeLists are lists of elements from object properties like .childNodes and
methods like getElementsByTagName(). Because these objects are live
(updated immediately when the underlying document changes), they are memory
intensive and can take up many CPU cycles. If you need a NodeList for only a
moment, it is faster to index directly into the list. Browsers are optimized to access
node lists this way. So instead of this:

18 Herea Adrian

nl = document.getElementsByTagName("P");

for (var i = 0; i < nl.length; i++) {

p = nl[i];

}

Do this:

for (var i = 0; (p =
document.getElementsByTagName("P")[i]); i++)

In most cases, this is faster than caching the NodeList. In the second example, the
browser doesn't need to create the node list object. It needs only to find the element at
index i at that exact moment.

Use Object Literals

Object literals work like array literals by assigning entire complex data types to
objects with just one command. So instead of this:

car = new Object();

car.make = "Honda";

car.model = "Civic";

car.transmission = "manual";

car.miles = 1000000;

car.condition = "needs work";

Do this:

car = {

make: "Honda",

model: "Civic",


transmission: "manual",

miles: 1000000,

condition: "needs work"

}

This saves space and unnecessary DOM references.

Local Optimizations

Okay, you've switched to a better algorithm and revamped your data structure.
You've refactored your code and minimized DOM interaction, but speed is still an
issue. It is time to tune your code by tweaking loops and expressions to speed up hot
spots. In his classic book, Writing Efficient Programs (Prentice Hall, 1982), Jon
Bentley revealed 27 optimization guidelines for writing efficient programs. These
code-tuning rules are actually low-level refactorings that fall into five categories:
space for time and vice versa, loops, logic, expressions, and procedures. In this
section, I touch on some highlights.

Trade Space for Time

Many of the optimization techniques you can read about in Bentley's book and
elsewhere trade space (more code) for time (more speed). You can add more code to
your scripts to achieve higher speed by "defactoring" hot spots to run faster. By
augmenting objects to store additional data or making it more easily accessible, you
can reduce the time required for common operations.

In JavaScript, however, any additional speed should be balanced against any
additional program size. Optimize hot spots, not your entire program. You can
compensate for this tradeoff by packing and compressing your scripts.
Augment Data Structures

Douglas Bagnall employed data structure augmentation in the miniscule 5K chess
game that he created for the 2002 5K contest (http://www.the5k.org/). Bagnall used
augmented data structures and binary arithmetic to make his game fast and small. The
board consists of a 120-element array, containing numbers representing either pieces,
empty squares, or "off-the-board" squares. The off-the-board squares speed up the

20 Herea Adrian

testing of the sides—preventing bishops, etc., from wrapping from one edge to the
other while they're moving, without expensive positional tests.

Each element in his 120-item linear array contains a single number that represents
the status of each square. So instead of this:

board=[16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,
16,16,2,3,4,5,6,2,3,4,5,16,....]

He did this:

bstring="ggggggggggggggggggggg23456432gg11111111gg0000
... g";

for (z=0;z<120;z++){

board[z]=parseInt(bstring.charAt(z),35);

}

This base-35 value represents the squares on the board (parseInt using a radix of
35). As alpha "g" corresponds to 16 (the 5th bit; that is, bit 4), Bagnall says he
actually could have used base-17 instead of 35. Perhaps this will leave room for future
enhancements.

Each position on the board is encoded like this:

bit 4 (16): 0 = on board, 1 = off board.

bit 3 (8): 0 = white, 1 = black.

bits 0-2(7): 0 = empty, non-zero = the piece type:

1 - pawn

2 - rook

3 - knight

4 - bishop

5 - queen


6 - king

So to test the color of a piece, movingPiece, you'd use the following:

ourCol=movingPiece & 8; // what color is it?
8=black, 0=white

movingPiece &= 7; // now we have the color info,
dump it.

if(movingPiece > 1){ // If it is not a pawn.

Bagnall also checks that the piece exists (because the preceding code will return
white for an empty square), so he checks that movingPiece is non-empty. To see his
code and the game in action, visit the following sites:

http://halo.gen.nz/chess/
http://halo.gen.nz/chess/main-branch/ (the actual code)

Cache Frequently Used Values

One of the most effective techniques you can use to speed up your JavaScripts is to
cache frequently used values. When you cache frequently used expressions and
objects, you do not need to recompute them. So instead of this (see Code Sample 5):
Code Sample 5 A Loop That Needs Caching and Fewer Evaluations

var d=35;

for (var i=0; i<1000; i++) {

y += Math.sin(d)*10;

}

Code Sample 6 Caching Complex Calculations Out of a Loop

var d=35;

var math_sind = Math.sin(d)*10;

22 Herea Adrian

for (var i=0; i<1000; i++) {

y += math_sind;

}

Because Math is a global object, declaring the math_sind variable also avoids
resolving to a global object for each iteration. You can combine this technique with
minimizing DOM interaction by caching frequently used object or property
references. Simplify the calculations within your loops and their conditionals.

Cache your objects

One of the best kept secrets to boosting script performance is to cache your objects.
Often times, your script will repeatedly access a certain object, as in the following
demonstration:


for (i=0;i<document.images.length;i++)

document.images[i].src="blank.gif"

</script>

In the above, the object "document.images" is what's accessed multiple times. The
code to realizing it is inefficient, since the browser must dynamically look up
"document.images" twice during each loop (once to see if i<document.images, and
the other, to access and change the image's src). If you have 10 images on the page,
for example, that's 20 calls to the Images object right there. Excessive calls to
JavaScript objects can wear down the browser, not to mention your computer's
memory.
The term "cache your object" means storing a repeatedly access object inside a user
defined variable, and using that variable instead in subsequent references to the
object. The performance improvement can be significant. Here's a modified version of
the initial script using object caching:


var theimages=document.images

for (i=0;i<theimages.length;i++)


theimages[i].src="blank.gif"

</script>

Not only is the number of times document.images[] is referenced cut in half with
the above, but for each time it is referenced, the browser doesn't have to go through
document.images first, but goes straight to its containing array.
Remember to use object caching when calling highly nested DHTML objects, like
document.all.myobject, or document.layers.firstlayer etc.

Cache your scripts

You've "cashed in" your objects...another way to enhance script performance is the
cache the entire script, by including it in a .js file. The technique causes the browser to
load the script in question only once, and recall it from cache should the page be
reloaded or revisited.

<script type="text/javascript"
src="imagescript.js"></script>

Use script caching when a script is extremely large, or embedded across multiple
pages.

Understand the cost of your objects

The fact is, some JavaScript objects are less forgiving on the browser than others.
While recognizing exactly which isn't easy (and isn't the goal here), just becoming
aware of this fact is important.

Take, for example, these two properties:

-object.innerText //IE only
-object.innerHTML
Did you know that the second property demands multiple times the system
resources to call than the first? If all you're changing is the textual content of a <div>
or <span> and in IE only, innerText would definitely be the more efficient choice.
Another example are the CSS properties "display" and "visibility"; the former is
significantly more expensive than the later.

24 Herea Adrian

Store Precomputed Results

For expensive functions (like sin()), you can precompute values and store the
results. You can use a lookup table (O(1)) to handle any subsequent function calls
instead of recomputing the function (which is expensive). So instead of this:

function foo(i) {

if (i < 10) {return i * i - i;}

}

Do this:

values = [0*0-0, 1*1-1, 2*2-2, ..., 9*9-9];

function foo(i) {

if (i < 10) {return values[i];}

}

This technique is often used with trigonometric functions for animation purposes.
A sine wave makes an excellent approximation of the acceleration and deceleration of
a body in motion:

for (var i=1; i<=360; i++) {

sin[i] = Math.sin(i);

}

In JavaScript, this technique is less effective than it is in a compiled language like
C. Unchanging values are computed at compile time in C, while in an interpreted
language like JavaScript, they are computed at runtime.


Use Local versus Global Variables

Reducing the scope of your variables is not only good programming practice, it is
faster. So instead of this (see Code Sample 7):
Code Sample 7 Loop with Global Variable

function MyInnerLoop(){

for(i=0;i<1000;i++);

}

Code Sample 8 Loop with Local Variable

function MyInnerLoop(){

for(var i=0;i<1000;i++);

}
Local variables are 60 percent to 26 times faster than global variables for tight
inner loops. This is due in part to the fact that global variables require more time to
search up the function's scope chain. Local variables are properties of the function's
call object and are searched first. Netscape 6 in particular is slow in using global
variables. Mozilla 1.1 has improved speed, but this technique is relevant to all
browsers. See Scott Porter's local versus global test at http://javascript-
games.org/articles/local_global_bench.html.

Trade Time for Space

Conversely, you can trade time for space complexity by densely packing your data
and code into a more compact form. By recomputing information, you can decrease
the space requirements of a program at the cost of increased execution time.

Packing

Packing decreases storage and transmission costs by increasing the time to
compact and retrieve the data. Sparse arrays and overlaying data into the same space
at different times are two examples of packing. Removing spaces and comments are
two more examples of packing. Substituting shorter strings for longer ones can also
help pack data into a more compact form.

26 Herea Adrian

Interpreters

Interpreters reduce program space requirements by replacing common sequences
with more compact representations.
Some 5K competitors (http://www.the5k.org/) combine these two techniques to
create self-extracting archives of their JavaScript pages, trading startup speed for
smaller file sizes (http://www.dithered.com/experiments/compression/). See Chapter
9, "Optimizing JavaScript for Download Speed," for more details.

Optimize Loops

Most hot spots are inner loops, which are commonly used for searching and
sorting. There are a number of ways to optimize the speed of loops: removing or
simplifying unnecessary calculations, simplifying test conditions, loop flipping and
unrolling, and loop fusion. The idea is to reduce the cost of loop overhead and to
include only repeated calculations within the loop.

Combine Tests to Avoid Compound Conditions

"An efficient inner loop should contain as few tests as possible, and preferably
only one."14 Try to simulate exit conditions of the loop by other means. One
technique is to embed sentinels at the boundary of data structures to reduce the cost of
testing searches. Sentinels are commonly used for arrays, linked lists, and binary
search trees. In JavaScript, however, arrays have the length property built-in, at least
after version 1.2, so array boundary sentinels are more useful for arrays in languages
like C.
One example from Scott Porter of JavaScript-Games.org is splitting an array of
numeric values into separate arrays for extracting the data for a background collision
map in a game. The following example of using sentinels also demonstrates the
efficiency of the switch statement:

var serialData=new;

Array(-1,10,23,53,223,-1,32,98,45,32,32,25,-
1,438,54,26,84,-1,487,43,11);

var splitData=new Array();

function init(){

var ix=-1,n=0,s,l=serialData.length;

for(;n<l;n++){


s=serialData[n];

switch(s){ // switch blocks are much more efficient

case -1 : // than if... else if... else if...

splitData[++ix]=new Array();

break;

default :

splitData[ix].push(s);

}

}

alert(splitData.length);

}
Scott Porter explains the preceding code using some assembly language and the
advantage of using the switch statement:
"Here, -1 is the sentinel value used to split the data blocks. Switch blocks should
always be used where possible, as it's so much faster than an if—else series. This is
because with the if else statements, a test must be made for each "if" statement,
whereas switch blocks generate vector jump tables at compile time so NO test is
actually required in the underlying code! It's easier to show with a bit of assembly
language code. So an if/else statement:

if(n==12)

someBlock();

else if(n==26)

someOtherBlock();

becomes something like this in assembly:

cmp eax,12;

jz someBlock;

28 Herea Adrian

cmp eax,26;

jz someOtherBlock;

Whereas a switch statement:

switch(a){

case 12 :

someBlock();

break;

case 26 :

someOtherBlock();

break;

}

becomes something like this in assembly:

jmp [VECTOR_LIST+eax];

where VECTOR_LIST would be a list of pointers to the address of the start of the
someBlock and someOtherBlock functions. At least this would be the method if the
switch were based on a numeric value. For string values I'd imagine eax would be
replaced by a pointer to the location of a string for the comparison.
As you can see, the longer the if...else if... block became, the more efficient the
switch block would become in comparison."15
Next, let's look at some ways to minimize loop overhead. Using the right
techniques, you can speed up a for loop by two or even three times.

Hoist Loop-Invariant Code

Move loop-invariant code out of loops (otherwise called coding motion out of
loops) to speed their execution. Rather than recomputing the same value in each
iteration, move it outside the loop and compute it only once. So instead of this:


for (i=0;i<iter;i++) {

d=Math.sqrt(y);

j+=i*d;

}

Do this:

d=Math.sqrt(y);

for (i=0;i<iter;i++) {

j+=i*d;

}

Reverse Loops

Reversing loop conditions so that they count down instead of up can double the
speed of loops. Counting down to zero with the decrement operator (i--) is faster than
counting up to a number of iterations with the increment operator (i++). So instead of
this (see Code Sample 9):
Code Sample 9 A Normal for Loop Counts Up

function loopNormal() {

for (var i=0;i<iter;i++) {

// do something here

}

}


30 Herea Adrian

Code Sample 10 A Reversed for Loop Counts Down

function loopReverse() {

for (var i=iter;i>0;i--) {


}

}

Flip Loops

Loop flipping moves the loop conditional from the top to the bottom of the loop.
The theory is that the do while construct is faster than a for loop. So a normal loop
(see Code Sample 9) would look like this flipped (see Code Sample 11):
Code Sample 11 A Flipped Loop Using do while

function loopDoWhile() {

var i=0;

do

{

i++;

}

while (i<iter);

}

In JavaScript, however, this technique gives poor results. IE 5 Mac gives
inconsistent results, while IE and Netscape for Windows are 3.7 to 4 times slower.
The problem is the complexity of the conditional and the increment operator.
Remember that we're measuring loop overhead here, so small changes in structure and
conditional strength can make a big difference. Instead, combine the flip with a
reverse count (see Code Sample 12):


Code Sample 12 Flipped Loop with Reversed Count

function loopDoWhileReverse() {

var i=iter;

do

{

i--;

}

while (i>0);

}

This technique is more than twice as fast as a normal loop and slightly faster than a
flipped loop in IE5 Mac. Even better, simplify the conditional even more by using the
decrement as a conditional like this (see Code Sample 13):
Code Sample 13 Flipped Loop with Improved Reverse Count

function loopDoWhileReverse2() {
var i=iter-1;
do
{
}
while (i--);
}

This technique is over three times faster than a normal for loop. Note the
decrement operator doubles as a conditional; when it gets to zero, it evaluates as false.
One final optimization is to substitute the pre-decrement operator for the post-
decrement operator for the conditional (see Code Sample 14).
Code Sample 14 Flipped Loop with Optimized Reverse Count

function loopDoWhileReverse3() {

var i=iter;

do

32 Herea Adrian

{


}

while (--i);

}

This technique is over four times faster than a normal for loop. This last condition
assumes that i is greater than zero. Table 10.2 shows the results for each loop type
listed previously for IE5 on my Mac PowerBook.
Table 10.2 Loop Optimizations Compared

Do Reverse Do while Do while Do while
while Reverse Reverse2 Reverse3
Total 2022 1958 1018 932 609 504
Time(ms)
Cycle time 0.0040 0.0039 0.0020 0.0012 0.0012 0.0010
(ms)

Unroll or Eliminate Loops

Unrolling a loop reduces the cost of loop overhead by decreasing the number of
times you check the loop condition. Essentially, loop unrolling increases the number
of computations per iteration. To unroll a loop, you perform two or more of the same
statements for each iteration, and increment the counter accordingly. So instead of
this:

var iter = number_of_iterations;

for (var i=0;i<iter;i++) {

foo();

}

Do this:


var iter = multiple_of_number_of_unroll_statements;

for (var i=0;i<iter;) {

foo();i++;

foo();i++;

foo();i++;

foo();i++;

foo();i++;

foo();i++;

}

I've unrolled this loop six times, so the number of iterations must be a multiple of
six. The effectiveness of loop unrolling depends on the number of operations per
iteration. Again, the simpler, the better. For simple statements, loop unrolling in
JavaScript can speed inner loops by as much as 50 to 65 percent. But what if the
number of iterations is not known beforehand? That's where techniques like Duff's
Device come in handy.

Duff's Device

Invented by programmer Tom Duff while he was at Lucasfilm Ltd. in 1983,16
Duff's Device generalizes the loop unrolling process. Using this technique, you can
unroll loops to your heart's content without knowing the number of iterations
beforehand. The original algorithm combined a do-while and a switch statement. The
technique combines loop unrolling, loop reversal, and loop flipping. So instead of this
(see Code Sample 15):
Code Sample 15 Normal for Loop

testVal=0;

iterations=500125;

for (var i=0;i<iterations;i++) {

// modify testVal here

}

34 Herea Adrian

16. Tom Duff, "Tom Duff on Duff's Device" [electronic mailing list], (Linköping,
Sweden: Lysator Academic Computer Society, 10 November 1983 [archived
reproduction]), available from the Internet at http://www.lysator.liu.se/c/duffs-
device.html. Duff describes the loop unrolling technique he developed while at
Lucasfilm Ltd.

Code Sample 16 Duff's Device

function duffLoop(iterations) {

var testVal=0;

// Begin actual Duff's Device

// Original JS Implementation by Jeff Greenberg
2/2001

var n = iterations / 8;

var caseTest = iterations % 8;

do {

switch (caseTest)

{

case 0: [modify testVal here];

case 7: [ditto];

case 6: [ditto];

case 5: [ditto];

case 4: [ditto];

case 3: [ditto];

case 2: [ditto];

case 1: [ditto];


}

caseTest=0;

}

while (--n > 0);

}
Like a normal unrolled loop, the number of loop iterations (n = iterations/8) is a
multiple of the degree of unrolling (8, in this example). Unlike a normal unrolled
loop, the modulus (caseTest = iterations % 8) handles the remainder of any leftover
iterations through the switch/case logic. This technique is 8 to 44 percent faster in
IE5+, and it is 94 percent faster in NS 4.7.

Fast Duff's Device

You can avoid the complex do/switch logic by unrolling Duff's Device into two
loops. So instead of the original, do this (see Code Sample 17):
Code Sample 17 Fast Duff's Device

function duffFastLoop8(iterations) {

// from an anonymous donor to Jeff Greenberg's site

var testVal=0;

var n = iterations % 8;

while (n--)

{

testVal++;

}

n = parseInt(iterations / 8);

while (n--)

{

36 Herea Adrian

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

}

}

This technique is about 36 percent faster than the original Duff's Device on IE5
Mac. Even better, optimize the loop constructs by converting the while decrement to a
do while pre-decrement like this (see Code Sample 18):
Code Sample 18 Faster Duff's Device

function duffFasterLoop8(iterations) {

var testVal=0;

var n = iterations % 8;

if (n>0) {

do

{

testVal++;

}

while (--n); // n must be greater than 0 here

}


n = parseInt(iterations / 8);

do

{

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

testVal++;

}

while (--n);

}

This optimized Duff's Device is 39 percent faster than the original and 67 percent
faster than a normal for loop (see Table 10.3).
Table 10.3 Duff's Device Improved

500.125 Normal For Duff’s Duff’s Duff’s
iterations Loop Device Fast Faster
Total time (ms) 1437 775 493 469
Cycle time (ms) 0.00287 0.00155 0.00099 0.00094

38 Herea Adrian

How Much to Unroll?

To test the effect of different degrees of loop unrolling, I tested large iteration
loops with between 1 and 15 identical statements for the Faster Duff's Device. Table
10.4 shows the results.
Table 10.4 Faster Duff's Device Unrolled

Duff‟s faster 1 Degree 2 3 4 5 6 7 8 9
Total time (ms) 925 661 576 533 509 490 482 469 467
Cycle time(ms) 0.00184 0.00132 0.00115 0.00106 0.0101 0.00097 0.00096 0.00093 0.00093

As you can see in Table 10.4, the effect diminishes as the degree of loop unrolling
increases. Even after two statements, the time to loop through many iterations is less
than 50 percent of a normal for loop. Around seven statements, the time is cut by two-
thirds. Anything over eight reaches a point of diminishing returns. Depending on your
requirements, I recommend that you choose to unroll critical loops by between four
and eight statements for Duff's Device.

Fuse Loops

If you have two loops in close proximity that use the same number of iterations
(and don't affect each other), you can combine them into one loop. So instead of this:

for (i=0; i<j; i++) {

sumserv += serv(i);

}

for (i=0; i<j; i++) {

prodfoo *= foo(i);

}

Do this:

for (i=0; i<j; i++) {

sumserv += serv(i);

prodfoo *= foo(i);

}


Fusing loops avoids the additional overhead of another loop control structure and is
more compact.

Loop benchmarking test suite result

Using the http://blogs.sun.com/greimer/resource/loop-test.html# we can see the
difference in performance for different ways of coding loops in JavaScript.
Accessing the length property is more expensive on HTML collections than on
arrays, depending on the browser. In those cases, caching it made a huge difference.
However, HTML collections are live, so a cached value may fail if the underlying
DOM is modified during looping. On the other hand, HTML collections will never be
sparse, so the best way to loop an HTML collection might just be to ignore the length
property altogether and combine the test with the item lookup .
Test environment: Mozila Firefox 3.0.14/Windows XP SP3/ Celeron D 2.8 GHz

Native Array (length=1000, looped 100 times)
Basic for loop. 15ms
for (var i=0; i<arr.length; i++)
{ }
For loop, but 13ms
for (var i=0, len=arr.length;
caching the length.
i<len; i++) { }
While loop that 13ms
var i = 0; while (i < arr.length)
imitates a for loop.
{ i++; }
While loop that 7ms
var i = 0, len = arr.length;
imitates a for loop,
while (i < len) { i++; }
caching the length.
While loop in 4ms
var i = arr.length; while (i--) {
reverse, simplifying
}
the test condition.
do ... while loop in 4ms
var i = arr.length-1; do { }
reverse.
while (i--);
for loop in reverse. 4ms
for (var i=arr.length; i--;) { }
While looping by 26ms
var x; while (x = arr.pop()) { }
popping values (this
fails on sparse
arrays).
for ... in loop 56ms
for (var i in arr) { }
for ... in loop, with 258ms
var isInt = /(^[0-9]$)|(^[1-9][0-
integer test

40 Herea Adrian

9]+$)/; for (var i in arr) {
if(!isInt.test(i)){continue;} }
For loop, testing on 8ms
for (var i=0; arr[i]; i++) { }
existence rather than
length (this fails on
sparse arrays).
for (var i=0; arr[i]; i++) { var
x = arr[i]; }
length, plus array
lookup.
for (var i=0, x; x = arr[i++];) {
}
length, array lookup
is combined with
test.
For reference. 14ms
for (var i=0, len=arr.length;
i<len; i++) { var x = arr[i]; }
Array.forEach() 17ms
arr.forEach(function(x){});
native
implementation.
For reference against 29ms
var f=function(x){}; for (var
forEach().
i=0, len=arr.length; i<len; i++)
{ f(arr[i]); }

Sparse Native Array (length=12705, sporadically populated with 1000 items,
looped 100 times)
for (var i=0; i<sarr.length; i++)
{ }
For loop, but 128ms
for (var i=0, len=sarr.length;
caching the length.
i<len; i++) { }
var i = 0; while (i < sarr.length)
{ i++; }
var i = 0, len = sarr.length;
caching the length.
While loop in 43ms
var i = sarr.length; while (i--) {
reverse,
}
simplifying the test
condition.

42 Herea Adrian

for (var i=0; hColl[i]; i++) { }
existence rather
than length (this
fails on sparse
arrays).
for (var i=0; hColl[i]; i++) { var
existence rather
x = hColl[i]; }
than length, plus
array lookup.
for (var i=0, x; x = hColl[i++];)
existence rather
{ }
than length, array
lookup is combined
with test.
for (var i=0, x; x =
existence rather
hColl.item(i++);) { }
than length, array
lookup is combined
with test, item()
instead of array
brackets.
For reference. 299ms
for (var i=0, len=hColl.length;
i<len; i++) { var x = hColl[i]; }

Expression Tuning

As regular expression connoisseurs can attest, tuning expressions themselves can
speed up things considerably. Count the number of operations within critical loops
and try to reduce their number and strength.
If the evaluation of an expression is costly, replace it with a less-expensive
operation. Assuming that a is greater than 0, instead of this:

a > Math.sqrt(b);

Do this:

a*a > b;

Or even better:


var c = a*a;

c>b;

Strength reduction is the process of simplifying expensive operations like
multiplication, division, and modulus into cheap operations like addition, OR, AND,
and shifting. Loop conditions and statements should be as simple as possible to
minimize loop overhead. Here's an example from Code Sample 10. So instead of this:

for (var i=iter;i>0;i--)
Do this:

var i=iter-1;

do {} while (i--);
This technique simplifies the test condition from an inequality to a decrement,
which also doubles as an exit condition once it reaches zero.

Miscellaneous Tuning Tips

You can use many techniques to "bum" CPU cycles from your code to cool down
hot spots. Logic rules include short-circuiting monotone functions, reordering tests to
place the least-expensive one first, and eliminating Boolean variables with if/else
logic. You also can shift bits to reduce operator strength, but the speed-up is minimal
and not consistent in JavaScript.
Be sure to pass arrays by reference because this method is faster in JavaScript. If a
routine calls itself last, you can adjust the arguments and branch back to the top,
saving the overhead of another procedure call. This is called removing tail recursion.

Flash ActionScript Optimization

Like JavaScript, ActionScript is based on the ECMAScript standard. Unlike
JavaScript, the ActionScript interpreter is embedded within Macromedia's popular
Flash plug-in and has different performance characteristics than JavaScript. Although
the techniques used in this chapter will work for Flash, two additional approaches are
available to Flash programmers. You can speed up Flash performance by replacing
slower methods with the prototype command and hand-tune your code with Flasm.

44 Herea Adrian

Flasm is a command-line assembler/disassembler of Flash ActionScript bytecode.
It disassembles your entire SWF file, allowing you to perform optimizations by hand
and replace all actions in the original SWF with your optimized routines. See
http://flasm.sourceforge.net/#optimization for more information.

You can replace slower methods in ActionScript by rewriting these routines and
replacing the originals with the prototype method. The Prototype site
(http://www.layer51.com/proto/) provides free Flash functions redefined for speed or
flexibility. These functions boost performance for versions up to Flash 5. Flash MX
has improved performance, but these redefined functions can still help.

Bibliography 45

Bibliography

Website Optimization: Speed, Search Engine & Conversion Rate Secrets
Andrew King,
O'Reilly Media, Inc.; 1 edition (15 Jul 2008)

Image Optimization: How Many of These 7 Mistakes Are You Making
Stoyan Stefanov (Yahoo! Inc)
2:00pm Tuesday, 06/24/2008
http://en.oreilly.com/velocity2008/public/schedule/detail/2405

High Performance Web Sites - 14 Rules for Faster-Loading Web Sites
by Steve Souders
http://stevesouders.com/hpws/rules.php

Even Faster Web Sites
Steve Souders (Google)
http://sites.google.com/site/io/even-faster-web-sites

Optimization Impact
By Patrick Meenan
http://blog.patrickmeenan.com/

YSlow: Yahoo's Problems Are Not Your Problems
by Jeff Atwood
http://www.codinghorror.com/blog/archives/000932.html

http://performance.webpagetest.org:8080/
http://developer.yahoo.com/performance/
http://developer.yahoo.com/performance/rules.htm
http://www.ryandoherty.net/
http://www.hostscope.com/c/templature/
http://www.slideshare.net/stoyan/yslow-20-presentation
http://blogs.sun.com/greimer/resource/loop-test.html
http://www.thewojogroup.com/2008/10/10-easy-steps-to-great-website-optimization/
http://code.google.com/intl/es/speed/articles/

Other online java script tutorials and forums/blogs about java script/web page
performance.

46 Herea Adrian

Content

Web Client performance .......................................................................................... 1
Prologue ................................................................................................................... 2
The Pareto Principle ............................................................................................. 2
The importance of performance ........................................................................... 2
Advices for fast web page inspired by YSlow ......................................................... 3
1. Make Fewer HTTP Requests ........................................................................... 3
2. Use a Content Delivery Network ..................................................................... 3
3. Add an Expires Header .................................................................................... 4
4. Gzip Components ............................................................................................. 4
5. Put CSS at the Top ........................................................................................... 5
6. Move Scripts to the Bottom ............................................................................. 5
7. Avoid CSS Expressions ................................................................................... 5
8. Make JavaScript and CSS External .................................................................. 6
9. Reduce DNS Lookups ...................................................................................... 6
10. Minify JavaScript ........................................................................................... 6
11. Avoid Redirects .............................................................................................. 6
12. Remove Duplicate Scripts .............................................................................. 7
13. Configure ETags ............................................................................................ 7
Optimizing JavaScript For Execution Speed ............................................................ 8
Design Levels ....................................................................................................... 8
Measure Your Changes ........................................................................................ 9
Algorithms and Data Structures ......................................................................... 10
Refactor to Simplify Code.................................................................................. 11
Minimize DOM Interaction and I/O................................................................... 11
Minimize Object and Property Lookups ........................................................ 12
Shorten Scope Chains..................................................................................... 13
Avoid with Statements ................................................................................... 13
Add Complex Subtrees Offline .......................................................................... 14
Edit Subtrees Offline .......................................................................................... 16
Concatenate Long Strings .................................................................................. 17
Access NodeLists Directly ................................................................................. 17
Use Object Literals ............................................................................................. 18
Local Optimizations ........................................................................................... 19
Trade Space for Time ......................................................................................... 19
Cache Frequently Used Values ...................................................................... 21
Cache your objects ......................................................................................... 22
Cache your scripts .......................................................................................... 23
Understand the cost of your objects ............................................................... 23
Store Precomputed Results ............................................................................. 24
Use Local versus Global Variables ................................................................ 25
Trade Time for Space ......................................................................................... 25
Packing ........................................................................................................... 25
Interpreters ..................................................................................................... 26
Optimize Loops .................................................................................................. 26

Content 47

Combine Tests to Avoid Compound Conditions ............................................ 26
Hoist Loop-Invariant Code ............................................................................. 28
Reverse Loops ................................................................................................ 29
Flip Loops ...................................................................................................... 30
Unroll or Eliminate Loops .............................................................................. 32
Duff's Device .................................................................................................. 33
Fast Duff's Device .......................................................................................... 35
How Much to Unroll? .................................................................................... 38
Fuse Loops ..................................................................................................... 38
Loop benchmarking test suite result ................................................................... 39
Expression Tuning ............................................................................................. 42
Miscellaneous Tuning Tips ................................................................................ 43
Flash ActionScript Optimization ........................................................................ 43
Bibliography........................................................................................................... 45
Content ................................................................................................................... 46

Web Client Performance

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Web Client Performance

Similar to Web Client Performance (20)

Recently uploaded

Recently uploaded (20)

Web Client Performance