Bandwidth and Performance
Optimizations

Once Apple made the strategic decision to support Web - based applications for iPhone and iPod
touch rather than native applications, optimization emerged as a front burner issue for application
developers. With native applications, programmers can code in their personal style, efficient or
not, because the actual performance hit is negligible, even on a mobile device like iPhone. What ’ s
more, 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 it
different from normal Web 2.0 apps is that the developer can no longer rely on the fact that the
user is accessing the application from a broadband connection. iPhone users may be coming to
your application using Wi - Fi or a much slower EDGE 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.
Your Optimization Strategy
If you spend much time at all researching optimization strategy and techniques, you quickly
discover that there are two main schools of thought. The first camp is referred to as hyper - optimizers
in this book. A hyper - optimizer 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 read-
ability of the code that 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.
c09.indd 209c09.indd 209 12/7/07 2:55:43 PM12/7/07 2:55:43 PM
Chapter 9: Bandwidth and Performance Optimizations
210
Decide which camp you fall into. But at the same time, 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 don ’ t offer any notable performance boost.
Best Practices to Minimize Bandwidth
Arguably the greatest bottleneck of any iPhone and iPod touch application is the time it takes to
transport data from the Web server to Mobile Safari, especially if your application is running over
EDGE. Therefore, consider the following techniques as you assemble your Web application.
General

Separate your page content into separate .css, .js, and .html files so that each file can be cached
by Mobile Safari.
Reduce white space (tabs and spaces) wherever possible. Although this might seem like a
nominal issue, the amount of excess white space 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 make it harder to manage your code in the future.
Use shorter filenames. For example, it is much more efficient to reference tb2.png than
TopBannerAlternate2_980.png.
Minimize the total number of external style sheets and JavaScript library files you include with
your page. Because browsers typically make just two requests at a given time, every additional
file that a browser has to wait on for the request to complete will create latency.
Write well - formed and standard XHTML code. While not a bandwidth issue, well - formed
XHTML requires less passes and parsing by Mobile 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, un - optimized JavaScript library for development (mylibrary.js) and then output a
compressed version for runtime purposes (mylibrary - c.js). (See the following section for more

on compression options.)
Images

Large image sizes are a traditional bottleneck to always 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.
❑
❑
❑
❑
❑
❑
❑
❑
❑
❑
c09.indd 210c09.indd 210 12/7/07 2:55:44 PM12/7/07 2:55:44 PM
Chapter 9: Bandwidth and Performance Optimizations
211
Make sure your images are sized appropriately for display on the iPhone and iPod touch
viewport. Never ever rely on browser scaling. Instead, match image size to image presentation.
Image data is more expensive than text data. Therefore, consider using canvas drawing in
certain cases.
Instead of using image borders, consider using CSS borders instead, particularly with the
enhanced
-webkit-border-radius
property.
Instead of using one large background image, consider using a small image and tiling it.
CSS and JavaScript


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 file size of the archive file indicates
the HTML page size with all of the external resources (images, style sheets, and script libraries)
associated with it.
Compressing Your Application
Normally, an iPhone/iPod touch Web application will be launched when a user types the URL in their
Mobile Safari browser. The Web server will respond to the HTTP request and serve the HTML file and

each of the many supporting files that are used in the display and execution of the Web app. While
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 will always take up much more space
❑
❑
❑
❑
❑
❑
c09.indd 211c09.indd 211 12/7/07 2:55:44 PM12/7/07 2:55:44 PM
Chapter 9: Bandwidth and Performance Optimizations
212
than if it were compressed. Therefore, with that idea in mind, several options are available to compress
files and/or JavaScript code on the fly on the server.
Gzip File Compression
Mobile Safari provides support for gzip compression, a compression option offered by many Web
servers. 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 Mobile Safari must uncompress
the resources when it receives them, be sure to test to ensure that this overhead does not eliminate the
benefits gained.
To turn on gzip compression in PHP, use the following code:

< ?php
ob_start(“ob_gzhandler”);
? >
< html >
< body >
< p > This page has been compressed. < /p >
< /body >
< /html >

JavaScript Code Compression
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 minify — remove all unnecessary characters — your JavaScript
code. In fact, using these automated solutions, you can potentially reduce the size of your scripts by
30 – 40 percent.
There are a variety of open source solutions that you turn to that tend to take two different approaches.
The safe optimizers remove whitespace and comments from code, but do not seek to actually change
naming inside of your source code. The aggressive optimizers go a step further and seek to crunch
variable and function names. While the aggressive optimizers achieve greater compression ratios, they
are not as safe to use in certain situations. For example, if you have
eval()
or
with
in your code (not
recommended anyway), these routines will be 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 uncompression 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 (
www.julienlecomte.net/blog/2007/08/13/introducing-the-
yui-compressor
) is a recently introduced optimizer that claims to offer a happy medium
between the conservative JSMin and the more aggressive ShrinkSafe and Packer listed next.

❑
❑
c09.indd 212c09.indd 212 12/7/07 2:55:45 PM12/7/07 2:55:45 PM
Chapter 9: Bandwidth and Performance Optimizations
213
Dojo ShrinkSafe (
alex.dojotoolkit.org/shrinksafe
) optimizes and crunches local variable
names to achieve greater compression ratios.
Dean Edwards ’ s Packer (
dean.edwards.name/packer
) is an aggressive 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 them to accurately
remove excess whitespace.
Additionally, while Packer requires semicolons, Dojo ShrinkSafe does not require them and will actually
insert missing semicolons for you. So you can pre - process 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 9 - 1 displays the results.
❑
❑
Table 9 - 1: Benchmark of Compression of i UI .js File

Compressor
JavaScript compression
(bytes)

With gzip compression
(bytes)
No compression 100 % (11284) 26 % (2879)
JSMin 65 % (7326) 21 % (2403)
Dojo ShrinkSafe 58 % (6594) 21 % (2349)
YUI Compressor 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
).
c09.indd 213c09.indd 213 12/7/07 2:55:45 PM12/7/07 2:55:45 PM