Adventures in HTML5: Mobile WebKit Performance Optimization

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.
3 comments
Martin1982
Martin1982

Very good stuff, I'm curious what will be next

Martin1982
Martin1982

Very good stuff, I'm curious what will be next

dfeldman
dfeldman

My thinking on this has evolved; stay tuned for a follow-up post.