Thinking 320×480: Load-Time Considerations For The iPhone & iPod touch
While we were working on WPtouch it quickly became clear that we would have to start considering all the ways we could accomplish a full-featured theme in the lowest file size possible, something that I’m sure many developers have faced when building web-based applications for Apple’s devices. While at times frustrating and challenging, the knowledge we gained from working within the limitations of the iPhone/iPod touch added optimization skills into our work coffers- some of which we already employ now in our client developent. In short, speed and size consideration for Apple devices has made our regular web projects even more refined and incredibly fast.
OVERWEIGHT AND BLOATED?
Having taken the broadband world for granted, we wanted to include some Ajax functions and Scriptaculous-based effects naturally, to add ‘ohh and awe’ to the theme. Though Scriptaculous (being built on the 90k Prototype) is heavy duty when it comes to mobile Safari’s capability to swallow it, and it soon proved to be a major blockade to developing the theme in the ways we had imagined.
I don’t have real-world stats for the comparison on hand as I write this, but our testing revealed that we’d have to explore other options to accomplish a lighter bandwidth footprint and still have the features we wanted, because it was disastrously slow.
Our preference was to use Scriptaculous, mostly because we were both familiar with it, and had a library of prepared code to draw up to speed up the development cycle. In short- we were lazy and looking for a quick fix to the predicament.
Enter compression. Now, I don’t claim to be an authority on this matter, as are there who need to take advantage of compression for mission critical application use, but I do know that when it comes to the raw transfer time of compressed vs. uncompressed scripts that every kilobyte makes an enormous difference, especially when we’re talking EDGE on the iPhone.
SQUEEZING INTO THESE PANTS
The combined weight of the javascript effects on WPtouch is a staggering 48kb. Consider that Prototype, Scriptaculous (Effects only) and some custom iPhone/iPod touch specific code is contained in that tiny package. Uncompressed, it was over 170kb. That savings (nearly 4 times smaller) changed the page load times dramatically, and allowed us to go forward with our Prototype/Scriptaculous plans.
STYLE FIRST
We used CSS wherever possible to provide colours and shapes, and if it weren’t for the fact that mobile Safari doesn’t support its big brother’s capability for CSS transforms, we would have been able to skip out on Scriptaculous for effects and just transform everything using CSS only.
A PICTURE IS WORTH A THOUSAND BYTES
The same was true for images. Whenever I could, I used the smallest possible sizes for files using a combination of very tiny crops for repeating images, and the ‘Save for web’ option in Photoshop.
I could have saved likely 50% more in file size if I had chosen .jpg as the predominant file type, but I really loved the quality that .png images provided. Early testing showed the difference in load times with .jpgs was nominal compared to the washouts I was seeing in colour with them.
MORE WEIGHT TO LOSE
We continue to trim and squeeze more weight out of WPtouch, and as we move towards adding new features it will certainly be something that will remain a constant challenge. With the advent of theme-capability for the plugin, we imagine that users themselves will come up with some dazzling examples of optimization- something we’re looking forward to seeing. In the mean time we’ll be focused on improving the theme as it is, and dabbling with Mootools and jQuery in compressed forms, along with other scripts available on the web for performing the functions we need will be explored.
What’s your experience with compression and file-size trimming? Have you got tricks we (and our readers) would love to know about?
6 Comments
-
From discussions I’ve watched scroll by on iphonewebdev I get the impression that jQuery is the most popular library that people are using (or at least mentioning by name). Apple seems to be pushing http://www.sproutcore.com/ and using it themselves for desktop Safari at least.
As for optimizing, when you say “compression” do you mean ob_gzhandler gzip serving compression? Or do you mean using some compression/minification type tools on the source? Or both? Did you look into canvas tag drawing and SVG options to replace bitmap images?
“if it weren?t for the fact that mobile Safari doesn?t support its big brother?s capability for CSS transforms, we would have been able to skip out on Scriptaculous for effects and just transform everything using CSS only.”
Well, while I’m down at WWDC I’ll take notes for you in the “Enhancing Your iPhone Web Application with CSS Transforms and Animations” session then, shall I?
-
BNC Design Guru
2 years, 4 months
HAHA! Yes, please do take notes! I tried adding several different transforms (effects based) and they did not work, period. The transforms that did (rounded corners) I didn’t consider worthy of the title, but I should amend my article because I’m being so hard-assed on little mobile Safari.
By compression I mean minification- even big safari doesn’t like .gz files. If it did, we would have served them.
As for accessing the canvas as a JavaScript object and drawing upon it, I think load times are faster if it’s something I can create out of pure css, or a very small .png/.jpg. The least processing the better.
There’s no absolutes here either, I don’t think- you need to look at the web app/site that you’re working with, and focus predominantly on the fatty tissue it has and deal with it first and foremost. There’s a point you reach where the load time feels comfortable, and that’s where you have to hang your hat, I think.
That’s funny about sproutcore, as Apple’s been using Scriptaculous for quite awhile on apple.com.
But please do share what you find, Alex, that would be great.
-
I have used YUI Compressor for trimming down JavaScript and CSS and it’s one of the better minification/obfuscation tools out there (considering various benchmarks I have seen). It did considerably reduce my load times and whatnot, though the files I have started with weren’t that large to begin with.
In terms of performance (and I haven’t tried this yet) you could also use Firefox with a spoofed user agent (Mobile Safari) and Firebug + YSlow to see what else you could tweak. I don’t think there’s any “WebKit Tab” plugin for Firefox, but for Firebug alone it would be worth it.
It may be frustrating and challenging, but doesn’t it feel nice to squeeze performance out of something? Many programmers nowadays are far too liberal with their code since rigs are quite powerful, but I do enjoy the little tweaks every so often. Might be just me.
-
BNC Design Guru
2 years, 3 months
Totally agree- it’s always enjoyable to get that extra mileage- especially when working with the iPhone, as it makes quite an appreciable difference in the user experience.
-
First of all, let me say that WPtouch is an amazing piece of work. The attention to detail is stunning and it truly feels like a thoroughly realized iPhone webapp. That being said, I’ve found in general usage that it just doesn’t make that huge of a difference in page loads. The theme for my site is fairly complex and there’s no doubt that WPtouch speeds up loading on EDGE, but it’s just not fast enough for it to be a true revelation.
I hate it when people bitch about a great piece of free developer work, so that’s really not my intention here, I just want to weigh in by saying that priority #1, for me at least, for an iPhone theme should be load speed (keeping in mind that many of us didn’t spring for a new 3G). The consistency of the iPhone feel of the theme is amazing, but I’d gladly sacrifice some of the snazz for speed. Because, after all, we all probably like our native themes and wouldn’t enable an iPhone specific theme unless we wish to cater to the limitations of EDGE… just my 2 cents!
-
BNC Design Guru
2 years, 1 month
MATT:
Well said- and you’re right, the performance on EDGE is dismal, at best. Though we have new 3G phones ourselves, we are looking at the options available to us to reduce the load for EDGE performance. Expect to see vast improvements shortly.
