Comments aside, the only other easy way to reduce the size of your code is to remove the unnecessary whitespace from your files. In the case of XHTML and CSS, we can define whitespace as any unneeded space, tab, or line break that exists in the file. In the examples you’ve seen throughout the book, spaces, tabs, and line breaks exist only to keep the code clean and clear for those of you reading it. But just as with removing comments, you should remove whitespace from your production code that exists on the server.

Let’s first examine the whitespace that can and should be removed from XHTML code:

<div id="summary">
    <p>A Title Here.</p>
    <ul>
        <li>Item One</li>
        <li>Item Two</li>
    </ul>
    <pre>
This is preformatted
            text    and should
    be left alone.
    </pre>
</div>

The trick here is that you can strip out all of the tabs, spaces, and line feeds between and after the XHTML elements, except for the <pre> element because it is one element that should honor whitespace in a file. After removing the whitespace, the preceding example would look like this:

<div id="summary"><p>A Title Here.</p><ul><li>Item One</li><li>Item Two</li>
</ul><pre>
This is preformatted
            text    and should
    be left alone.
</pre></div>

As you can check, once you take out all of the extra spaces between elements, as well as all tabs and line feeds except for those within the <pre> element, this code still looks the same in the browser. The code snippet went from 216 bytes down to 173 bytes, saving 43 bytes in just 12 lines of code. These savings will add up, I guarantee it.

The whitespace in the CSS file is easier to remove than that in the XHTML file, because we do not have to concern ourselves with watching out for certain elements. Take a look at the following CSS snippet:

body {
    background-color: transparent;
    color: #000;
    padding: 2px 0;
    font-family: sans-serif;
}

#logo {
    background: url('../images/logo.png') no-repeat fixed center;
    color: #000;
}

The preceding code with all the whitespace stripped out would look something like the following:

body{background-color:transparent;color:#000;padding:2px 0;font-family:
sans-serif}#logo{background:url('../images/logo.png')no-repeat fixed
center;color:#000}

The original code is 203 bytes, whereas the optimized code is 158 bytes. I know this is a savings of only 45 bytes, but it is also only a small amount of code. The savings you can achieve when you have a full-fledged CSS file can be huge.

The second thing you can do to XHTML and CSS files in terms of code optimization is to shorten class and id names within the files. You can really reduce the size of your XHTML and CSS files with this technique.

Take a look at the following XHTML code:

<div id="highlight">
    <p class="text">Text</p>
    <ul id="ext">
        <li class="light">Item One</li>
        <li class="dark">Item Two</li>
    </ul>
</div>

Now, I know this code is silly, but it is designed with a purpose. Here’s the catch with changing names by hand: suppose you want to change the class named light to lt and the class named dark to dk, so you do a simple search and replace in your editor; if you did just a blanket replace all (because they are class names after all, and there may be a lot of them), you could end up with the following:

<div id="highlt">
    <p class="text">Text</p>
    <ul id="ext">
        <li class="lt">Item One</li>
        <li class="dk">Item Two</li>
    </ul>
</div>

In the preceding code, the id named highlight might have been renamed highlt by mistake, thus breaking any potential styles that were associated with this <div> element. Like I said, this is a simple example, but you can understand the problem you may have by changing names by hand, depending on what those names are.

Another pain to consider is that you may have to make these changes to every ex-HTML file that you have deployed, plus all of your corresponding CSS (and potentially JavaScript) files. Not only is this a lot of work, but you are setting yourself up for mistakes that will break your web application. You should seriously consider the risks and gains before going to this extreme.

Another tip that I can give you for optimizing CSS files is to use shorthand notation whenever possible. You may have noticed that in the CSS examples throughout this book, I always used shorthand notation in my code, whether it was to shorten hexadecimal color names or whether I used it for rules, padding, or margins. Small things such as this can provide great gains in the long run. Finally, make sure you allow your CSS files to cascade the way they should. If you are unsure how to program using these techniques, take a look at CSS: The Definitive Guide, Third Edition, by Eric Meyer (O’Reilly), for reference.

There are many tricks to reducing the size of a JavaScript file that are not available to other client-side code such as XHTML and CSS. Before we get to those, though, we can employ the same tricks these files use to shrink the size of the file.

Removing the comments in your JavaScript files, especially if you are using JSDoc comments to document your code, can greatly reduce the size of your code. You do not necessarily want everyone who downloads your JavaScript files to see what you commented on anyway. So, remove those comments from production files!

Then there is all the whitespace in a JavaScript file. Consider the following lines of JavaScript code.

function GetActiveSS( ) {
    for (var i = 0; (a = document.getElementsByTagName('link')[i]); i++)
        if (a.getAttribute('rel').indexOf('style') != -1 &&
                a.getAttribute('title') && !a.disabled)
            return a.getAttribute('title'),
    return (null);
}

We can remove whitespace in plenty of places in this code. Here is the same code, with the whitespace removed:

function GetActiveSS( ){for(var i=0;(a=document.getElementsByTagName('link')[i]);
i++)if(a.getAttribute('rel').indexOf('style')!=-1&&a.getAttribute('title')&&!
a.disabled)return a.getAttribute('title'),return(null)}

The code is not affected in the least, as the semicolon (;) separates commands in JavaScript, but the size of the snippet went from 267 bytes to 212 bytes, a savings of 55 bytes. This is a small size advantage in this example, but with a full JavaScript file, you can really reduce the size of the file.

Often you will find that you need to test whether a value is valid or invalid. This usually involves testing whether something equals true, false, null, or undefined. This is demonstrated in the following:

if (myValue == true) {
    // execute code
}

if (myValue != null) {
    // execute code
}

if (myValue != undefined) {
    // execute code
}

All of these are correctly written statements, and they work just fine, but we can rewrite them all by testing the variable, and in case of the != by using the NOT operator:

if (myValue) {
    // execute code
}

if (!myValue) {
    // execute code
}

This reduces the size of the script without affecting its operation. When the JavaScript is parsed, it does a type conversion on myValue, making it true, false, null, or undefined, and voilà! This type conversion may also produce a 1 or 0, which can optimize Boolean variables a bit more throughout your script. Take a look at the following code segment:

var isOk = false;

for (var i = 0; isOk || i < anArray.length; i++) {
    if (anArray[i] == 'found')
        isOk = true;
    else {
        // execute code
    }
}

This segment contains only two Boolean variables, but what about code that uses and sets Boolean values all over the place? Keep in mind as you look at this segment of code again that the Boolean values are only being substituted for 0 and 1:

var isOk = 0;

for (var i = 0; isOk || i < anArray.length; i++) {
    if (anArray[i] == 'found')
        isOk = 1;
    else {
        // execute code
    }
}

This simple code change does nothing to alter the outcome of this code segment, but it can save you three bytes for every instance of true and four bytes for every instance of false. That can add up to a lot of savings, and it is a very simple change.

The final way to save on size in a JavaScript file is by using array and object literals. An array literal is a list of zero or more expressions that are enclosed in square brackets ([]), where each expression represents an array element. When an array is created in this way, it is initialized to the values specified in the list, and the length of the array is set to the number of expressions listed.

Here is how you are first taught by any JavaScript book to create arrays:

var bookTypes = new Array( );

bookTypes[0] = 'Fiction';
bookTypes[1] = 'Children's Literature';
bookTypes[2] = 'History';

It is the traditional way, and perfectly legitimate—it is easy to understand exactly what is happening in the code without the need for comments. However, our aim is for smaller size, not ease of understanding. It takes 126 bytes to declare the array in this way. We can reduce that like this:

var bookTypes = new Array('Fiction', 'Children's Literature', 'History'),

Here, we set all of the array elements from within the array constructor. Declaring an array in this way reduces the size of the code considerably. It takes only 74 bytes to declare the array in this way, but now let’s look at using an array literal:

var bookTypes = ['Fiction', 'Children's Literature', 'History'];

This takes our code segment down to 65 bytes, which is a small decrease from the second code segment, but a savings nonetheless. Using array literals to create your arrays is just a good practice to get into.

Object literals are similar to array literals; an object literal is a list of zero or more expression pairs that are enclosed in curly braces ({}), where each expression pair represents a property name and its associated value. Creating an object in this way initializes it and creates the properties that were defined in the expression list.

function book(p_title, p_isbn) {
    this._title = p_title;
    this._isbn = p_isbn;
    this.getTitle = function( ) {
        return this._title;
    };
}

var newBook = new book('Ajax: The Definitive Guide', '0-596-52838-8'),

The preceding code segment is not really much of an object, but it is enough to give you an idea of what we are aiming at. That first bit of code is 234 bytes long. We can reduce it to this:

var newBook = new Object( );

newBook._title = 'Ajax: The Definitive Guide';
newBook._isbn = '0-596-52838-8';
newBook.getTitle = function( ) { return this._title; };

The preceding code segment creates the same object as the previous segment, but the number of bytes with this code is 167. Now, we will create the object using an object literal:

var newBook = { _title: 'Ajax: The Definitive Guide', _isbn: '0-596-52838-8',
getTitle: function( ) { return _title; }};

This takes our object down to 119 bytes, a pretty big savings over our original object creation segment and even a pretty good gain over our second example. It is a good idea to take advantage of this ability when creating your objects, as it gives good byte savings.

Perhaps the more important part of JavaScript optimization, execution time affects how your application runs once it has been downloaded to the client. Some of the enhancements that I will show you for optimizing your JavaScript code may not be easy to implement for one reason or another, but others you should always implement to achieve speed enhancements consistently.

An important part of JavaScript is the ability to assign variables in your code. However, did you know that where your variables are declared in your code can make a difference in terms of a program’s execution speed? It is important to define your variables at the scope in which they will be used. This is because it takes CPU cycles to test every level, from the current level of execution to the top level of the program. The less the parser has to search to find the variable it needs to execute with, the faster the program’s execution time will be. As a general rule of thumb, global variables are bad. Not that they don’t serve their purpose, but they create longer execution time because of their scope. For example:

for (i = 0; i < 20; i++)
    alert(i + '<br />
'),

That’s a stupid example, I know, but the point is that this code would execute more quickly if the variable was defined within the scope of the loop, like this:

for (var i = 0; i < 20; i++)
    alert(i + '<br />
'),

There are two optimization techniques that you can easily apply to most for loops. The first is all about setting a local variable to any value that would have to be looked up and pulled out each time through the loop. A good example of this is looking up the lengths of arrays. For example:

var count = 0;

for (var i = 0; i < arrNumbers.length; i++)
    count += arrNumbers[i];

You could optimize the preceding code as follows:

var count = 0;

for (var i = 0, il = arrNumbers.length; i < il; i++)
    count += arrNumbers[i];

The other for loop optimization has to do with what operations are faster for JavaScript to execute. It is easier for JavaScript to test a value against zero than it is to test against a number. What we want to do, then, is reverse the loop so that it counts down and checks for zero instead of checking in the other, more common direction. The speed gains on a small for loop are negligible; with larger loops, however, you will start to notice them. Here is an example loop:

var count = 0;

for (var i = arrNumbers.length - 1; i > 0; i--)
    count += arrNumbers[i];

These optimizations are trivial compared to accessing and manipulating the Document Object Model (DOM) document. Doing so is one of the most costly operations that you can perform as a JavaScript programmer. Every DOM manipulation will in some way change the way the page is displayed to the user, because to make sure the page is rendered correctly, it must recalculate every last object and element on the page. This takes a significant amount of time, in computing terms, so keep in mind that every time you add, modify, or delete something from the DOM structure, you will be increasing the amount of time that your code takes to execute. To keep these calculations and times to a minimum, you should create objects outside of the DOM and manipulate the DOM with these objects instead of directly.

Suppose we want to add an array of titleDsc strings that contain the description of a book title to a <div> element with an id of descript, separating each item in the array with a <br> element:

var i = 0, il = titleDsc.length;
var dsc = document.getElementById('descript'),

/* Loop through the array while there are elements */
do {
    dsc.appendChild(document.createTextNode(titleDsc[i]));
    i++;
    /* Are there still elements to parse? */
    if (i < il)
        dsc.appendChild(document.createElement('br'));
} while (i < il);

There are a couple of problems with this code segment—not with the code itself (it executes just fine), but rather in terms of the speed at which it executes. The first problem is the first dsc.appendChild( ) call, which adds a text node to the <div> element to be updated. The second problem is that the second dsc.appendChild( ) call, which adds a <br> element to the <div> element descript, causes the page to recalculate so that it can be displayed correctly to the user. Just with these two problems, you are causing the page to recalculate two times every trip through the loop. Suppose that there are 15 items in the titleDsc array; that would mean the page must recalculate a total of 30 times when this segment is executed.

To reduce the number of page recalculations, use a document fragment to hold all of the text nodes and <br> elements until the loop has completed, and then add the fragment to the DOM:

var i = 0, il = titleDsc.length;
var dsc = document.getElementById('descript'),
var frag = document.createDocumentFragment( );

/* Loop through the array while there are elements */
do {
    frag.appendChild(document.createTextNode(titleDsc[i]));
    i++;
    /* Are there still elements to parse? */
    if (i < il)
        frag.appendChild(document.createElement('br'));
} while (i < il);
dsc.appendChild(frag);

In this new version of the code segment, a document fragment is created outside the DOM before we start looping. Then, the text nodes and <br> elements are added to the fragment inside the loop, before the fragment is finally added to the <div> element that is already part of the DOM document after the loop has completed.

You can do other little things to speed up the execution of your code as well. For instance, did you know that you can define more than one variable with a single var statement? Moreover, it does not matter whether you define variables of different types within this single var. Remember, eliminating lines of code that the client must parse allows your code to run faster. Consider the following code segment that defines three variables:

var count = 3;
var title = 'The Coolest Page Ever';
var tabs = ['Tab One', 'Tab Two', 'Tab Three'];

We can use a single var statement to define all three of these variables, thus speeding up the segment:

var count = 3, title = 'The Coolest Page Ever', tabs = ['Tab One', 'Tab Two',
'Tab Three'];

Another simple way to speed up code execution is to store a value in a local variable if you need to use that value more than twice. This is even more important if you get the values from the property of an object or directly from an object in the DOM. For instance:

var fontSizes = p_xhrResponse.responseXML.getElementsByTagName(
'languageChanges').item(0).getElementsByTagName(
'fontSizes').item(0).firstChild.data;
var languages = p_xhrResponse.responseXML.getElementsByTagName(
'languageChanges').item(0).getElementsByTagName(
'languageSwitch').item(0).firstChild.data;
var mapLink = p_xhrResponse.responseXML.getElementsByTagName(
'languageChanges').item(0).getElementsByTagName(
'mapLink').item(0).firstChild.data;

document.getElementById('fontSizes').innerHTML = fontSizes;
document.getElementById('languages').innerHTML = languages;
document.getElementById('mapLink').innerHTML = mapLink;

You could use a variable to store the value of the root node in this code segment, as well as the responseXML, for that matter. You could optimize it like this:

var xmlDocument = p_xhrResponse.responseXML;
var root = xmlDocument.getElementsByTagName('languageChanges').item(0);
var fontSizes = root.getElementsByTagName('fontSizes').item(0).firstChild.data;
var languages = root.getElementsByTagName('languageSwitch').item(0).firstChild.data;
var mapLink = root.getElementsByTagName('mapLink').item(0).firstChild.data;

document.getElementById('fontSizes').innerHTML = fontSizes;
document.getElementById('languages').innerHTML = languages;
document.getElementById('mapLink').innerHTML = mapLink;

The last optimization techniques are related to the incrementing and decrementing operators. As a quick refresher to everyone, incrementing and decrementing operators increase and decrease their variables by one numeric value using (++) and (--), respectively. Whenever you are using these operators, consider your code and decide whether you can combine multiple statements into one statement. For example:

1 var i = 0, il = titleDsc.length;
2 var dsc = document.getElementById('descript'),
3 var frag = document.createDocumentFragment( );
4
5 /* Loop through the array while there are elements */
6 do {
7     frag.appendChild(document.createTextNode(titleDsc[i]));
8     i++;
9     /* Are there still elements to parse? */
10     if (i < il)
11         frag.appendChild(document.createElement('br'));
12 } while (i < il);
13 dsc.appendChild(frag);

You can combine the statements on lines 7 and 8 in the preceding code into one statement by placing the incrementing operator line of code into the preceding line:

var i = 0, il = titleDsc.length;
var dsc = document.getElementById('descript'),
var frag = document.createDocumentFragment( );

/* Loop through the array while there are elements */
do {

    frag.appendChild(document.createTextNode(titleDsc[i++]));
    /* Are there still elements to parse? */
    if (i < il)
        frag.appendChild(document.createElement('br'));
} while (i < il);
dsc.appendChild(frag);

This is possible because the incrementing operators in this case are placed postfix, or after the variable, and the value of i is increased after the rest of the statement has been executed. Remember to check your code to make sure that combining statements will not affect the outcome and will only help to reduce parsing.

We could make other, more detailed optimizations as well, but they deal with less common coding statements and more complicated techniques. A good book on this subject is Speed Up Your Site: Web Site Optimization by Andrew B. King (New Riders).

Of course, the client side is not the only side of an Ajax application, and we will now turn our attention to server-side optimization techniques.

Inline queries are SQL statements that are written dynamically by server code before being executed on the server. In general, these types of queries run more slowly than if you executed the same code in a stored procedure (more on this in the next section). Even though they are slower, there are a few good practices you can use that can lead to faster code statements. You should apply these best practices to the code in stored procedures as well.

The first good practice for returning data quicker is to only return the data that the application actually needs. For an example, take a look at the following SQL statement:

SELECT * FROM my_table WHERE column2 = valueX;

This kind of code is commonly written by developers, but it is not optimized. Why? This code queries a table and returns every column in the table that meets the given criteria. The problem with this is that if code like this is executed on a table that has millions of records and a good number of columns, the amount of data being returned will potentially be huge. Instead, the preceding code should look something like this:

SELECT column2, column3, column5 FROM my_table WHERE column2 = valueX;

Remember that you should never request more data than you actually need. By doing this, you can significantly speed up query execution time as well as the time it takes to process this data on the server by requiring less memory to deal with it.

Another good SQL keyword to avoid is UNION. When this must be executed against two SELECT statements, which hopefully have followed my first good practice or there will be real trouble here, it causes SQL to do a lot of work that will slow the execution time considerably. Try to avoid this at all costs. It is a speed killer, unless small SELECT results are being combined in this way. So, instead of doing something like this:

SELECT
    t1.column1,
    t1.column2,
    t1.column3,
    t2.column7
FROM
    table1 t1 INNER JOIN table2 t2 ON t1.column1 = t2.column2
WHERE
    t1.column1 = value1 AND
    t2.column7 IS NOT NULL
UNION
SELECT
    column1,
    column2,
    column3,
    column4
FROM
    table3
WHERE
    column1 = value1

you would do something like this:

CREATE TEMPORARY TABLE temp_table1(col1 INTEGER,
                                   col2 INTEGER,
                                   col3 VARCHAR(30),
                                   col4 DATE);
INSERT INTO temp_table1
SELECT
    t1.column1,
    t1.column2,
    t1.column3,
    t2.column7
FROM
    table1 t1 INNER JOIN table2 t2 ON t1.column1 = t2.column2
WHERE
    t1.column1 = value1 AND
    t2.column7 IS NOT NULL;
INSERT INTO temp_table1
SELECT
    column1,
    column2,
    column3,
    column4
FROM
    table3
WHERE
    column1 = value1;
SELECT * FROM temp_table1;

This solution will avoid the potential performance problems that UNION can give you, and will give you improved join performance should you need to join the UNION results to other tables. In fact, should you require another join, you could improve this even more by adding a primary key to the temporary table.

SQL, like most other languages, provides more than one way to accomplish almost anything. If you feel that a query you have written is not performing as quickly as it should, contact your database administrator, if you have one, and have him take a look. If a database administrator is not at your disposal, try forums or Internet relay chat (IRC), or refer to a book. There may be a better way to write your query.

Sometimes, however, what you wrote is not necessarily bad, but it still runs slowly. When this happens, first look at the indexes on the tables you are querying. Perhaps one or more tables require an additional index put on them. With MySQL, you can accomplish this with the following:

CREATE INDEX _ndx_table1_column2 ON table1 (column2);

This code puts an index called _ndx_table1_column2 on table table1 for column2, which the name obviously implies. Naming an index in a meaningful way can go a long way toward simplifying database maintenance and troubleshooting. This will keep your database administrator happier—something that is always worthwhile to do.

I want to make it clear that I am not suggesting that you throw indexes on tables just because your database queries are running slowly. You must do this correctly or you will end up with another problem: your database may start to take up too much space. This will make your database administrator angrier—something that is never worthwhile to do.

Indexes help out only so much.

If you are still having problems with speed, I can suggest one more thing. Check what SQL functions you are using in your code. Functions such as IFNULL( ) can affect the speed of a statement depending on how it is used. Take the following code, for example:

SELECT
    t1.col1,
    t1.col2,
    t2.col2 AS col3,
    IFNULL(t3.col2, 'none') AS col4,
    IFNULL(t3.col3, 'empty') AS col5
FROM
    table1 t1 INNER JOIN table2 t2 ON t1.col1 = t2.col1
    LEFT OUTER JOIN table3 t3 ON t1.col2 = t3.col1
WHERE
    t1.col3 IS NOT NULL AND
    t2.col2 = 1
GROUP BY
    t1.col1,
    t1.col2,
    t2.col2,
    IFNULL(t3.col2, 'none'),
    IFNULL(t3.col3, 'empty')

When a function must be called for every record multiple times, chances are good that this will slow your code. Some of the usual suspects (in MySQL) are functions such as CASE, NULLIF( ), REPLACE( ), SOUNDS_LIKE( ), and the function I already mentioned, IFNULL( ). Do not avoid these functions, as they do have real benefits, but beware of what could happen should you use them as I showed in the preceding example.

Stored procedures will generally take less time to run than an inline query pulling the same results. However, stored procedures will have the same issues with performance as inline queries when the problems I just demonstrated exist in the stored procedure code. In fact, if you write a stored procedure incorrectly, it may not experience any speed gains over a dynamic query pulling those same results.

Stored procedures built with a number of parameters that may vary each time the procedure runs can hurt performance. When your stored procedure has been programmed to accept multiple parameters, but some of those parameters are optional and may not be used, do not write your stored procedure generically so that it does not care how many parameters it actually gets. Using this method can lead to unnecessary joins to tables that do not need to be joined, based on the parameters that were passed. These unnecessary joins lead to a small performance hit that can be avoided. Instead of coding your stored procedure generically, include IF...ELSE logic into your stored procedure and write separate queries for each combination of parameters. Now, you can ensure that the stored procedure runs as efficiently as possible.

The trick, however, is that you must take this one step further so that your SQL server does not recompile the stored procedure every time, and that is to call other stored procedures that handle every combination of possible parameters. For example:

CREATE PROCEDURE example1_sp (param1 INTEGER, param2 INTEGER, param3 INTEGER)
BEGIN
    IF param1 IS NULL AND param2 IS NULL AND param3 IS NULL THEN
        CALL example2_sp
    ELSEIF param2 IS NULL AND param3 IS NULL THEN
        CALL example3_sp(param1)
    ELSEIF param3 IS NULL THEN
        CALL example4_sp(param1, param2)
    ELSE
        CALL example5_sp(param1, param2, param3)
    END IF
END

With this type of stored procedure, the server will always optimize a query plan, and you will not suffer the speed losses that would occur should stored procedures not be called from within the main stored procedure.

The best advice I can offer on stored procedures, and on SQL statements in general, is that you should always use EXPLAIN to analyze the plan the query will use to execute the SQL statements. It is easiest to spot potential problems from the query plan, and to fix them, before they become issues in production.