In a decade where broadband is now the norm, many Web developers have fallen into those same tendencies and allow their sites and applications to be composed of ill-formed HTML, massive JavaScript libraries, and multiple CSS style sheets.
However, when you are developing applications for iPhone and iPod touch, you need to refocus your programming and development efforts toward optimization and efficiency. What makes them different from normal Web apps is that the developer can no longer rely on the fact that users are accessing the application from a broadband connection. iPhone users may be coming to your application using Wi-Fi or a slower 3G connection.
Therefore, as you develop your applications, you will want to formulate an optimization strategy that makes the most sense for your context. You'll want to think about both bandwidth and code performance optimizations.
If you spend much time at all researching optimization strategies and techniques, you quickly discover two main schools of thought. The first camp is referred to as hyper-optimizers in this book. They will do almost anything to save a byte or an unneeded call to the Web server. They are far more concerned with saving milliseconds than they are about the readability of the code they are optimizing. The second camp, perhaps best described as relaxed optimizers, are interested in optimizing their applications. But they are not interested in sacrificing code readability and manageability in an effort to save a nanosecond here or there.
Decide which camp you fall into. At the same time, though, don't go through complex optimization hoops unless you prove that your steps are going to make a substantive difference in the usability of your application. Many optimization techniques you'll find people advocating may merely make your code harder to work with and not offer notable performance boost.
Arguably the greatest bottleneck of any iPhone Web app is the time it takes to transport data from the Web server to Safari, especially if your application is running over 3G. You can certainly opt for local offline caching (see Chapter 11, "Offline Applications"). However, you should also consider the following techniques as you assemble your Web application.
Separate your page content into separate CSS, JS, and HTML files so that each file can be cached by Safari on iPhone.
Meanwhile, studies show that loading additional files takes up 60-90 percent of the total time of a Web page. Therefore, be sure to minimize the total number of external style sheets, JavaScript library files, and images you include with your page. Because browsers typically make two to four requests at a given time, every additional file that a browser has to wait on for the request to complete will create latency.
Reduce whitespace (tabs and spaces) wherever possible. Although this might seem like a nominal issue, the amount of excess whitespace can add up, particularly on a larger-scale Web application with dozens of files.
Remove useless tags, and unused styles and JavaScript functions in your HTML, CSS style sheets, and JavaScript library files.
Remove unnecessary comments. However, keep in mind the following caveat: removing comments can reduce file size, but it can also make it harder to manage your code in the future.
Use shorter filenames. For example, it is much more efficient to reference
tb2.pngthanTopBannerAlternate2_980.png.Write well-formed and standard XHTML code. Although not a bandwidth issue, well-formed XHTML requires fewer passes and parsing by Safari before it renders the page. As a result, the time from initial request to final display can be improved through this coding practice.
Consider using gzip compression when you serve your application. (See the following section for more on compression options.)
Consider using a JavaScript compressor on your JavaScript libraries. You could then work with a normal, unoptimized JavaScript library for development (
mylibrary.js) and output a compressed version for runtime purposes (mylibrary-c.js). (See the following section for more on compression options.)
Large image sizes are a traditional bottleneck to target for your applications. Be meticulous in optimizing the file size of your images. Shaving off 5Kb or so from several images in your application can make a notable performance increase.
Make sure your images are sized appropriately for display on the iPhone viewport. Never rely on browser scaling. Instead, match image size to image presentation.
Image data is more expensive than text data. Therefore, consider using a canvas drawing in certain cases.
Instead of using image borders, consider using CSS borders, particularly with the enhanced
-webkit-border-radiusproperty.Instead of using one large background image, consider using a small image and tiling it.
Use CSS sprites to combine multiple image files into a larger one. The overall latency impact is reduced because fewer requests are made to the server.
Combine rules to create more efficient style declarations. For example, the second declaration is much more space efficient than the first one is:
// Less efficient div #content { font-family: Helvetica, Arial, sans-serif; font-size: 12px; /* Randy: do we want this as px or pt? */ line-height: 1.2em; /* Let's try this for now.*/ font-weight: bold; } // More efficient div #content {font: bold 12px/1.2em Helvetica, Arial, sans-serif};Consider using shorter CSS style names and JavaScript variable and function names. After all, the longer your identifiers are, the more space your files will take. But, at the same time, do not make your identifiers so short that they become hard to work with. For example, consider the trade-offs with the following three declarations:
/* Inefficient */ #homepage-blog-subtitle-alternate-version{letter-spacing:.1em;} /* Efficient, but cryptic */ #hbsa{letter-spacing:.1em;} /* Happy medium */ #blog-subtitle-alt{letter-spacing:.1em;}
As you work through these various strategies and test results, a good way to check the total page size is to save the page as a Web archive in a desktop version of Safari. The size of the archive file indicates the HTML page size with all the external resources (images, style sheets, and script libraries) associated with it.
Normally, an iPhone Web application is launched when users type the URL in their Safari browser (or click its shortcut icon on the iPhone home screen). The Web server responds to the HTTP request and serves the HTML file and each of the many supporting files that are used in the display and execution of the Web app. Although image files may have been optimized as much as possible to minimize bandwidth, each uncompressed HTML file, CSS style sheet, and JavaScript library file requested takes up much more space than if it were compressed. With that idea in mind, several options are available to compress files or JavaScript code on the fly on the server.
Safari supports gzip compression, which many Web servers offer. Using gzip compression, you can reduce the size of HTML, CSS, and JavaScript files and reduce the total download size by up to 4 to 5 times. However, because Safari must uncompress the resources when it receives them, be sure to test that this overhead does not eliminate the benefits gained.
For example, if you wanted to turn on gzip compression in PHP, you could use the following code:
<?php
ob_start("ob_gzhandler");
?>
<html>
<body>
<p>This page has been compressed.</p>
</body>
</html>In addition to reducing the total file size of your Web site, another technique is to focus on JavaScript code. These compression strategies go far beyond the manual coding techniques described in this chapter and seek to compress and remove all unnecessary characters in your JavaScript code. In fact, using these automated solutions, you can potentially reduce the size of your scripts by 30-40 percent.
You can turn to a variety of open source solutions, which tend to take two different approaches. The safe optimizers remove whitespace and comments from code but do not seek to change naming inside of your source code. The hyper-optimizers go a step further and seek to crunch variable and function names. While the hyper-optimizers achieve greater compression ratios, these ratios are not as safe to use in certain situations. For example, if you have eval() or with in your code (not recommended anyway), they are broken during the compression process. What's more, some of the optimizers, such as Packer, use an eval-based approach to compress and uncompress. However, there is a performance hit in the decompression process, and it could actually slow down your script under certain conditions.
Here are some of the options available (ranked in order of conservatism employed in their algorithms):
JSMin (JavaScript Minifier;
www.crockford.com/javascript/jsmin.html) is perhaps the best-known JavaScript optimizer. It is the most conservative of the optimizers, focusing on simply removing whitespace and comments from JavaScript code.YUI Compressor (
http://developer.yahoo.com/yui/compressor/) is an optimizer that claims to offer a happy medium between the conservative JSMin and the more aggressive ShrinkSafe and Packer listed next.Dojo ShrinkSafe (
www.dojotoolkit.org/docs/shrinksafe) optimizes and crunches local variable names to achieve greater compression ratios.Dean Edwards's Packer (
dean.edwards.name/packer/) is a hyper-optimizer that achieves high compression ratios.
Deciding which of these options to use should depend on your specific needs and the nature of your source code. I recommend starting on the safe side and moving up as needed.
If you decide to use one of these optimizers, make sure you use semicolons to end your lines in your source code. Besides being good programming practice, most optimizers need these punctuation marks to accurately remove excess whitespace.
Additionally, whereas Packer requires semicolons, Dojo ShrinkSafe does not require them and actually inserts missing semicolons for you. So you can preprocess a JavaScript file through ShrinkSafe before using it in a semicolon-requiring compressor like Packer.
To demonstrate the compression ratios that you can achieve, I ran the iUI.js JavaScript library file through several of these optimizing tools. Table 13-1 displays the results.
Table 13-1. Benchmark of Compression of iUI.js File
Compressor | Javascript Compression (Bytes) | With Gzip Compression (Bytes) |
|---|---|---|
No compression | 100% (11284) | 26% (2879) |
65% (7326) | 21% (2403) | |
Dojo ShrinkSafe | 58% (6594) | 21% (2349) |
64% (7211) | 21% (2377) | |
YUI Compressor (w/Munged) | 46% (5199) | 18% (2012) |
YUI Compressor (w/Preserve All Semicolons) | 64% (7277) | 21% (2389) |
YUI Compressor (w/Munged and Preserve All Semicolons) | 47% (5265) | 18% (2020) |
One final option worth considering is a PHP-based open source project called Minify. Minify combines, minifies, and caches JavaScript and CSS files to decrease the number of page requests that a page has to make. To do so, it combines multiple style sheets and script libraries into a single download (code.google.com/p/minify/).
The performance of JavaScript on iPhone is slower than on the Safari desktop counterparts, although recent improvements in the iPhone 3.0 OS shrink this gap. For example, consider the following simple DOM-access performance test:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<title>Performance Test</title>
</head>
<body>
<form id="form1">
<input id="i1" value="zero" type="text">
</form>
<div id="output"></div>
</body>
<script type="text/javascript" language="javascript">
var i = 0;
var start1 = new Date().getTime();
divs = document.getElementsByTagName('div'),
for(i = 0; i < 80000; i++) {
var d = divs[0];
}
var start2 = new Date().getTime();
var delta1 = start2--start1;
document.getElementById("output").innerHTML = "Time: " + delta1;
</script>
</html>Safari for Mac OS X executes this script in 529 milliseconds, whereas Safari for iPhone takes 13,922 milliseconds. That's more than 26 times longer! Therefore, in addition to the optimizations you can make to shrink the overall file size of your application, you should give priority to making performance gains in execution based on your coding techniques. Here are several best practices to consider.
When working with client-side JavaScript, accessing the DOM can be at the heart of almost anything you do. However, as essential as these DOM calls may be, it is important to remember that DOM access is expensive from a performance standpoint and should be done with forethought.
Cache references that you make to avoid multiple lookups on the same object or property. For example, compare the following inefficient and efficient routines:
// Ineffecient
var str = document.createTextNode("Farther up, further in");
document.getElementById("para1").appendChild(str);
document.getElementById("para1").className="special";
// More efficient
var str = document.createTextNode("Farther up, further in");
var p = document.getElementById("para1");
p.appendChild(str);
p.className="special";What's more, if you make a sizeable number of references to a document or another common DOM object, cache them, too. For example, compare the following:
// Less efficient
var l1=document.createTextNode('Line 1'),var l2=document.createTextNode('Line 2'),
// More efficient
var d=document;
var l1=d.createTextNode('Line 1'),
var l2=d.createTextNode('Line 2'),If you reference document a handful of times, it is probably not practical to go through this trouble. But if you find yourself writing document a thousand times in your code, the efficiency gains make this practice a definite consideration.
When you are writing to the DOM, assemble your subtree of nodes outside of the actual DOM, and then insert the subtree once at the end of the process. For example, consider the following:
var comments=customBlog.getComments('index'),
var c=comments.count;
var entry;
var commentDiv = document.createElement('div'),
document.body.appendChild(commentDiv);
for (var i = 0; i < c; i++) {
entry=document.createElement('p'),
entry.appendChild( document.createTextNode(comments[i]);
commentDiv.appendChild(entry);
}Consider the placement of the grayed, highlighted line. Because you add the new div element to the DOM before you add children to it, the document must be updated for each new paragraph added. However, you can speed up the routine considerably by moving the offending line to the end:
var comments=customBlog.getComments('index'),
var c=comments.count;
var entry;
var commentDiv = document.createElement('div'),
for (var i = 0; i < c; i++) {
entry=document.createElement('p'),
entry.appendChild( document.createTextNode(comments[i]);
commentDiv.appendChild(entry);
}
document.body.appendChild(commentDiv);With the restructured code, you need to update the document display only once instead of multiple times.
Along the same line, you should avoid excessive document.write() calls because each call is a performance hit. A much better practice is to assemble a concatenated string variable first. For example, compare the following:
// Inefficient
document.write('<div class="row">'),
document.write('<label class="cui">office</label>'),document.write('<a class="cuiServiceLink" target="_self" href="tel:(765) 555-1212">
(765) 555-1212</a>'),
document.write('</div>'),
// More efficient
var s = '<div class="row">' + '<label class="cui">office</label>' +
'<a class="cuiServiceLink" target="_self" href="tel:(765) 555-1212">(765) 555-1212
</a>' + '</div>';
document.write(s);The window object is faster to use because Safari does not have to navigate the DOM to respond to your call. The following window reference is more efficient than the previous three approaches:
// Inefficient var h=document.location.href; var h=document.URL; var h=location.href; // More efficient var h=window.location.href
One of the most important practices JavaScript coders should implement in their code is use of local variables and avoidance of global variables. When Safari processes a script, local variables are looked for first in the local scope. If Safari can't find a match, it moves up the next level, and then the next, until it hits the global scope. So global variables are the slowest in a lookup. For example, defining variable a at the global level in the following code is much more expensive than defining it as a local variable inside of the for routine:
// Inefficient
var a=1;
function myFunction(){
for(var i = 0; i < 10; i++) {
var t = a+i;
// do something with t
}
}
//More efficient
function myFunction(){
for(var i = 0, a = 1; i < 10; i++) {
var t = a+i;
// do something with t
}
}Accessing objects and properties by dot notation is never efficient. Therefore, consider some alternatives.
Aim to keep the levels of dot hierarchy small. Nested properties, such as document.property.property.property, cause the biggest performance problems and should be avoided or accessed as few times as possible.
// Inefficient m.n.o.p.doThis(); m.n.o.p.doThat(); // More efficient var d = m.n.o.p; d.doThis(); d.doThat();
If you access a named object, it is more efficient to use getElementById() than to access it via dot notation. For example, compare the following:
// Inefficient
document.form1.addressLine1.value
// More efficient
document.getElementById('addressLine1').value;When accessing a property inside a loop, it is much better practice to cache the property reference first and then access the variable inside the loop. For example, compare the following:
// Inefficient
for(i = 0; i < 10; i++) {
var v = document.object.property(i);
var y = myCustomObject.property(i);
// do something
}
// More efficient
var p = document.object.property;
var cp = myCustomObject.property(i);
for(i = 0; i < 10; i++) {
var v= p(i);
var y=cp(i);
// do something
}Here's another example of using the length property of an object in the condition of a for loop:
// Inefficient
for (i = 0; i < myObject.length; i++) {
// Do something
}
// More efficient
var j = myObject.length;
for (i = 0,; i < j; i++) {
// Do something
}Similarly, if you are using arrays inside of loops and using its length as a conditional, you want to assign its length to a variable rather than evaluating at each pass. Check this out:
// Inefficient
myArray = new Array();
for (i = 0; i < myArray.length; i++) {
// Do something
}
// More efficient
myArray = new Array();
len = myArray.length;
for (i = 0; i < len; i++) {
// Do something
}Another traditional problem area in JavaScript is string concatenation. In general, you should try to avoid an excessive number of concatenations and an excessively large string that you are appending to. For example, suppose you are trying to construct a table in code and then write out the code to the document when you are finished. The stringTable() function in the following code is less efficient than the second function intermStringTable(), because the latter uses an intermediate string variable row as a buffer in the for loop.
<html>
<script type="text/javascript" language="javascript">
function stringTable() {
var start = new Date().getTime();
var buf = "<table>";
for (var i = 0; i < 10000; i++){
buf += "<tr>";
for (var j = 0; j < 40; j++){
buf += "<td>" + "content" + "</td>";
}
buf += "</tr>";
}
buf += "</table>";
var duration = new Date().getTime() -- start;
document.write('String concat method: ' + duration + '</br>'),
}
function intermStringTable(){
var start = new Date().getTime();var buf = "<table>";
for (var i = 0; i < 10000; i++){
var row = "<tr>";
for (var j = 0; j < 40; j++){
row += "<td>" + "content" + "</td>";
}
row += "</tr>";
buf += row
}
buf += "</table>";
var duration = new Date().getTime() -- start;
document.write('Intermediate concat method: ' + duration + '</br>'),
}
</script>
<body>
</body>
<script type="text/javascript" language="javascript">
stringTable();
intermStringTable();
</script>
</html>Be sure to avoid with statements, which slow the processing of the related code block. Besides the fact that with is inefficient, it has been deprecated in the JavaScript standard. Also, avoid using eval() in your scripts because it is expensive from a performance standpoint. Besides, you should be able to develop a more efficient solution than resorting to eval().
Comments add to readability and manageability, but be wise in their usage. For example, minimize their use inside of loop routines, functions, and arrays. If possible, place comments before or after a programming construct to ensure greater efficiency.
// Inefficient
var a = 0, c = 100;
for (var i = 0; i < c; i++) {
// Assign d the value of the next div in the current document
var d = document.getElementByTagName('div')[i];
// Perform some math for a
a=i * 1.2;
// Perform some math for b
b=(a + i) / 3;
}
// More efficient
// Assign val of d to 100 divs and perform y on them
// based on val of a and b.
var a = 0, c = 100;
for (var i = 0; i < c; i++) {
var d = document.getElementByTagName('div')[i];
a=i * 1.2;
b=(a + i) / 3;
}In this chapter, you focused on how to optimize your Web sites and apps. The great bottleneck of any iPhone Web app is the time it takes to move data from the Web server to the device. You will therefore want to separate your page content into separate files so that each file can be cached. At the same time, you will want to minimize the total number of these files. Also, focus considerable attention on image optimization. Large image sizes are a one of the greatest problems to deal with and so you will want to work hard to optimize the file size of your images.
A second area to focus on when optimizing your Web app is compression. Beyond image compression, consider compressing CSS style sheet and JavaScript library files. Using gzip compression, you can significantly reduce the download size of your Web app, as much as five times. What's more, consider using a JavaScript code compressor to shrink the size of your scripts by 40 percent.
Finally, in your JavaScript code, be sure to consider how to interact with the DOM of the page you are working with. You'll want to make use of variables and cache references that you make to avoid redundant lookups on the same DOM object. What's more, when you write to the DOM, be careful to minimize the number of successive document.write() calls. Combine when possible. Also, you'll want to assemble your subtree of nodes outside of the actual DOM, and then insert the subtree once at the end of the process. Finally, when possible, work with the window object instead of the document object or its children. The window object is faster and more efficient to call.