More Thoughts On Mobile Web App Performance

Last week, I wrote about Drew Crawford’s analysis of the elements affecting the poor performance of mobile web apps. In my post I noted that performance issues for my own mobile web app project were related to a large number of elements inserted into the DOM and the resulting memory footprint rather than pure JavaScript performance.

This week, Shai Almog posted a response to Drew’s analysis that highlighted how poor DOM performance can be a leading contributor to UI sluggishness in mobile web apps. This aligns to my own experience with DOM performance problems and I think its one that is faced by many mobile developers.

Most developers who are building a mobile web-app will look to one of the cross-platform user interface toolkits like jQuery Mobile (jQM). These toolkits greatly enhance developer productivity by providing pre-built user interface controls that mimic a native mobile application. For example, jQM will stylize buttons, lists, and navigation bars to provide a native look and feel. However, when jQM adds these styles it also adds a large number of elements into the DOM.

For example, jQM will convert a simple unordered list element:

<ul data-role="listview" data-inset="true" data-filter="true">
<li><a href="#">Acura</a></li>
</ul>

…into the following stylized list element:

<ul data-role="listview" data-inset="true" data-filter="true" class="ui-listview ui-listview-inset ui-corner-all ui-shadow">
<li data-corners="false" data-shadow="false" data-iconshadow="true" data-wrapperels="div" data-icon="arrow-r" data-iconpos="right" data-theme="c">
<div>
<div><a href="#" class="ui-link-inherit">Acura</a></div>
<span>&nbsp;</span>
</div>
</li>
</ul>

During the conversion jQM added 16 CSS styles and 4 sub-elements to the DOM (2 divs, 1 href, and one span). Now, imagine multiplying this across a list of say 20 items, a couple of data tables, plus a navigation bar in the header and a tab bar in the footer. What seems like a simple mobile UI can quickly grow into a real monster in the browser’s DOM!

In my experience with jQM, anytime you’re dealing with a list over 10-15 items or if you have a page with multiple stylized elements you’re going to start hitting performance problems. We addressed this by replacing jQM elements with normal HTML elements and our own custom, lightweight CSS. This added additional work during a critical time in the development process and I’ve since ditched jQM for a fully native UI on the new app I’ve been working on.

I don’t think I’d be willing to use a mobile web app approach to develop another app unless the app had only a simple user interface and very basic functional requirements. The time saved by using a web app framework like jQM simply isn’t that great and it limits the possibilities for unique interfaces and features because of its more limited feature set and poor performance.

One other note…my experience with mobile web app performance is based on a fairly complex enterprise app that was deployed on the iPad 4. However, we also used the same jQM interface on a desktop version of the app that could be accessed by users when they were in the office. Many of the desktops were using IE 8 as their browser because the app was used by a government agency that hadn’t yet fully upgraded to a newer browser. Our team saw the same performance issues and UI sluggishness on the desktops running IE 8 as we did on the iPad. If you’re unlucky enough to be developing a complex web application that targets IE 8 be ready to work on performance optimizations!