2

I've been developing a web app using JQM to target iOS and Android devices. For much of the start of the development, I have developed and tested using Chrome (currently v13) on the desktop. As we get closer to our production release deadline, I have increased testing on physical iOS and Android hardware; the difference in performance between the desktop and mobile browsing experience is enormous.

The client/server interaction is very simple. The client requests a set of views, which the server returns. The client can then request the set of nodes associated with a particular view, which the server will return in a single payload. The client then generates the DOM for each node from the corresponding XML.

I have begun testing with XML payloads at or greater than 400kb. On the desktop, in Chrome, this is no issue. On mobile, in Mobile Safari, my DOM load times alone can be close to 12 seconds. Interactions with the DOM (which trigger updates to the XML, cached in localStorage) can take up to 5 seconds per click.

While I can think of half a dozen different ways to optimize my client/server communication--I can't figure out how to measure the expense of my individual method calls from the mobile client. I know that a 400k payload is too much for the iOS Mobile Safari, but I don't know whether the performance cost I'm incurring comes from traversing the DOM or manipulating the XML.

How can I perform metric analysis of my mobile web app from the perspective of the mobile client? Performance tuning to the desktop isn't getting me anywhere, and I don't have an equivalent developer console/FireBug on the mobile side.

How do other mobile developers solve this problem?

dmon
  • 30,048
  • 8
  • 87
  • 96
Christopher
  • 1,723
  • 1
  • 18
  • 31

2 Answers2

1

I've decided to add a simple start/stop logging button, which calls a logging function which stores method timing data in sessionStorage. On stop logging, I ship this to a web service for analysis through a desktop browser.

Edit: I did try JsLitmus per this SO post, but I concluded that the only performance test that really matters on mobile is the time to execute any particular function. Once I had this information exported out of the client, performance tuning was trivial.

Community
  • 1
  • 1
Christopher
  • 1,723
  • 1
  • 18
  • 31
  • 1
    Much later, the single, cheapest and most effective optimization was data formatting. JSON is much cheaper and easier to assemble server-side, and once client-side it becomes JSO, which is significantly faster to parse and navigate than XML. – Christopher Sep 09 '11 at 03:08
0
  1. I don't know what sort of XML parsing JQM uses, but if it's using a DOM style parser, performance will suffer for sure. Mobile clients deal better with pull style parsers (they're less memory intensive). DOM style parsing of XML is really slow in native clients, I bet it will be even slower inside a browser.
  2. A 400 KB XML sure sounds like quite a big chunk of data. Do you really need all that at the same time?
  3. Heavy DOM manipulation has never been cheap, I expect performance will be pretty affected in a mobile device.

I guess this doesn't really answer your question, but it was pretty long to just place inside a comment.

dmon
  • 30,048
  • 8
  • 87
  • 96
  • 1: I'm parsing XML using jQuery (JQM doesn't have a separate implementation). It is a DOM style parser, if I understand you. It would be better to ship the data as JSON, but that is a big refactor and I want to have some performance data to justify it. 2: 400k is big. And I don't need it all at once. Again, before I refactor to break it into pieces, I want some metrics so that I can make it most efficient. 3: Yeah, that is the big unknown. No matter how much I optimize the payloads, I'm still creating huge DOM content. Again--how to perform metric performance analysis? – Christopher Jun 17 '11 at 02:29