The mobile Web app is gaining a lot of momentum as developers are discovering how powerful Web technologies can be and how their apps can benefit from HTML/CSS/JavaScript. What we love about using Web technologies to build our apps and wrapping them in PhoneGap is that it reuses a lot of knowledge that we’ve already mastered. Years had gone into developing our knowledge of HTML/CSS/JavaScript and instead of tossing all that out the window for mobile, we’re able to refine that knowledge even further. One thing we’re finding, however, is that we can’t build apps the same way we build websites–-obviously from a design standpoint, but also from a development standpoint. The Reflow The seemingly simple way a Web page is displayed is actually a pretty complex process: the initial display of a page triggers what is known as a reflow. During the reflow process, the content is combined with rules defined in the stylesheets and the measurements for the layout of the page are determined. After this process is completed, then the actual pixel data is rendered and painted to the screen. Every node on a page impacts the time it takes to do a reflow. On a desktop browser, often the performance impact seems to be relatively unnoticeable. The user impact at a 10ms reflow time is rather negligible. However, herein seems to be much of the performance loss on mobile devices. The same pages that take only 10ms to reflow on a desktop can take over 1000ms on a mobile device. Every single change to the DOM further impacts that time (this is part of the reason why JavaScript-based animation looks so terrible on mobile devices). Reducing the Cost of a Reflow So what does this mean for semantics and a mobile app? On the Web, semantic HTML is critical to a website being searchable by search engines like Google, as well as accessible to those using screen readers. HTML5 brings with it a whole host of new tags like <article> and <section> that help make the markup even more semantic and helps avoid the dreaded <div> soup that often plagued designs of any sort of complexity. However we’re finding that semantics is often needing to take a backseat to making efficient use of our HTML. For example, to generate a tableview-like structure, we use an unordered list. Instead of wrapping the content of each list item in an <a> tag, we simply listen for user interaction directly on the <li> node and remove the <a> all together. (Truth be told, we’re finding that a lot of our <a> tags are extraneous.) We’ve also started applying some basic styling to the <html> tag to avoid wrapping the entire body in a <div> when our content needs a wrapper (we figured the <html> tag was already there–might as well use it for something). Finally, we haven’t been using the new tags offered with HTML5 (like <section> or <article>) very often simply because <div> is shorter. What we’re working toward here is developing our apps so they spend less time in reflow. We’ve found that it is likely the reflow time that causes mobile web apps to “feel slow.” First, we need to shorten the time it takes to perform a reflow. We take care of this by removing extraneous tags: removing <a> tags when we can just listen for tap events on an <img> or <li>, cutting down on <div> wrappers, etc. Next, we need to limit the number of times a reflow is required. A reflow is triggered whenever the DOM is changed or the dimensions of an element change–this could be adding/removing an element or text, or changing the margins or font size of an element. Reducing the Number of Reflows The developer tools provided with the desktop version of Safari provide a great way to determine how changes to a page affect the need for a reflow/repaint. While it doesn’t give any sort of indication how long a reflow/repaint would take on a mobile device, using the timeline tab in the developer tools in Safari does give a good indication of how many reflows would be required (since Mobile Safari renders pages similarly to the desktop version). Unfortunately, we have yet to find a suitable tool for watching Mobile Safari’s processes. Let’s say you’re adjusting the style of a node in your JavaScript: [crayon-51dd7f676d588/] This “simple” style adjustment triggered three reflow/repaints of the page. On a desktop a reflow probably takes less than 15ms so it’s not a big deal. However, on a mobile device, a reflow can easily seem to take over 500ms which means that three reflows triggered in rapid succession could easily take a mobile device well over a second to finish processing. To avoid this, use classes to modify an element’s style whenever possible. Style changes applied because of a change in classes only triggers one reflow. Alternatively, use the cssText property to affect all the styles at once (again, only triggering one reflow): [crayon-51dd7f676d604/] Beyond changing the dimensions of an element, there are times when you may need to make a lot of changes to the DOM (perhaps when drastically updating a view). Unfortunately, every modification made to the DOM requires a reflow/repaint. Below shows the reflow/repaint cost of replacing the header on Float’s mobile site with the word “hi” wrapped in a <div>: To avoid a significant number of reflows being triggered, we need a way to modify the DOM without triggering reflows. The way to do that is to clone a node in the DOM, make changes to the clone, and then swap the old node with the new node. [crayon-51dd7f676d67d/] This will only trigger one (or maybe two) reflow/repaints where as making the changes directly on the element would have triggered four or five. The same principle applies when using a JavaScript framework like jQuery or Zepto.js–clone the item you’re modifying, make the modifications, and then swap it into the DOM. Here is the cost of the same modifications [...]![]()
