My previous post took a high-level look at HTML5 vs. native for mobile apps, concluding that HTML5 is ready for prime time but not necessarily for everyone. I also mentioned some of the work I did in order to get my app, Pints, to perform acceptably. Commenter Jouni (thanks for reading!) wondered about the details: what did I try, and what seemed to work?
I won’t claim to have used an incredibly rigorous process. As previously mentioned, I chose Sencha Touch as my framework almost exclusively based on its performance. At least on iPhone, I threw out PhoneGap in favor of a lightweight custom Cocoa wrapper. (I’m particularly skeptical about whether that ended up mattering, but it did allow me to create a better experience during app load by waiting until the page finishes loading before fading in the WebKit view.)
Inspired by Thomas Fuchs’ “Making an iPad HTML5 app & making it really fast,” I then did the following:
- Pints was routinely hanging for 10-15 seconds whenever the data stores for its lists got updated. Using the built-in WebKit debugger in desktop Safari (which was hanging for 3-5 seconds) I did a bunch of fairly trial-and-error exploration and finally tracked the problem down. Sencha Touch support grouped lists with an index bar, like the iPhone address book — a great feature which apparently slows to a crawl with larger lists. I reluctantly turned that off, reverting to flat lists and eliminating the problem.
- I gutted both my own CSS and Sencha’s, stripping out all images, CSS3 gradients, text shadow effects, and some of the CSS RGBA alpha transparency. The result kept layout-related rules but was mostly unstyled in all other respects. I also pulled out the CSS3 @font-face call, reverting from Ubuntu Sans to Helvetica. This served as my baseline and was acceptably fast for most page-slide and list-scroll operations.
- I then selectively turned things back on based on their importance to Pints’ look & feel and reasonable hypotheses about their potential performance impact. I assumed my static wood-grain background image would be less problematic than the semi-transparent gradient applied to each list item. I left out the custom font because it wasn’t that important. And so on. Each time I turned on another item I ran the app on the device and evaluated, ultimately arriving at a UI that was close to the original but far faster, and not appreciably slower than the baseline.