Tag Archives: jQuery Mobile

Analyzing script evaluation speed of jQuery & jQuery Mobile on the iPhone

In a previous post, I discussed how Javascript can slow down website loading speed significantly, and why Kamishibai and Ponzu aim to keep the size of Javascript small.

Today, I used the Safari web inspector to analyze how long it actually takes to evaluate jQuery Mobile, a common framework used for mobile web development.

For evaluation, we used the jQuery Mobile demo page for version 1.2.1.

Below are the results. We evaluated, in order, my MacBook Air with a 1.7GHz Intel Core i5 (Mac OS X 10.8.3), my iPhone 5 (iOS 6.1.3) and my iPhone 4S (iOS 6.1.3).

The numbers that we are interested in are the times that it takes to evaluate Javascript.

MacBook Air 1.7GHz Intel Core i5 2013 04 01 21 56 jQuery mobile MBA

MacBook Air 1.7GHz Core i5: Time taken to evaluate Javascript

  1. jquery-1.7.1.min.js – 10.7ms
  2. jquery.mobile-1.2.1.js – 31.5ms

iPhone 5 2013 04 01 21 56 jQuery Mobile iPhone 5

iPhone 5: Time taken to evaluate Javascript

  1. jquery-1.7.1.min.js – 41.7ms
  2. jquery.mobile-1.2.1.js – 144ms

iPhone 4s 2013 04 01 21 57 jQuery Mobile iPhone 4s

iPhone 4s: Time taken to evaluate Javascript

  1. jquery-1.7.1.min.js – 65.7ms
  2. jquery.mobile-1.2.1.js – 238ms

Conclusion

The total latency of evaluating jQuery Mobile (jquery.min.js + jquery.mobile.js) was 42.2ms for the MBA, 186.1ms for the iPhone 5, and 303.7ms for the iPhone 4s.

Network latencies for a good broadband WiFi connection are about 50ms. For a 3G connection, they are a few hundred ms.

Server latencies can depends a lot on the complexity of the page you wish to display, but can be anywhere between a few ms to a few seconds. We generally try to keep server latency less than 300ms, and for most pages, less than 100ms.

Whereas latencies of 100ms appear to be almost instantaneous to humans, response times of more that 300ms are very noticeable and negatively impact perceived responsiveness.

Given these numbers, and also considering that the iPhone 4s is by no means a slow phone, we conclude that jQuery mobile is still too slow. For the evaluation time of jQuery Mobile to get to the point that it doesn’t matter, we need at least twice the speed of the current iPhone 5. Given the performance increase with each iPhone model, we might see sufficient speed with the 2013 iPhone model. However, for such performance to become mainstream, we will probably have to wait about 3 years, especially considering that Android Javascript performance tends to significantly lag behind mobile Safari.

What is Kamishibai?

Below I describe the design goals of Kamishibai.

Kamishibai is a compositior

Kamishibai is a simple compositor, similar to the Quartz Compositor in Mac OS X. What this means can be illustrated by what Kamishibai does, and what it does not.

What Kamishibai does not.

  1. Kamishibai does not generate HTML from data through the use of templates.
  2. Kamishibai does not contain any business logic in the form of “Models”.
  3. Kamishibai is not a Javascript MVC framework.
  4. Kamishibai will never target native application development through phoneGap, etc. That’s not what Kamishibai is for.

What Kamishibai does.

  1. Kamishibai requests HTML fragments from the server and stores them in a local cache.
  2. Kamishibai replaces portions of the current DOM with HTML fragments from the server and displays them.
  3. Kamishibai intelligently places HTML fragments from the server into appropriate locations in the DOM based on attributes on the fragments.
  4. Kamishibai combines multiple fragments to generate a single DOM.
  5. Kamishibai local cache stores HTML fragments and also expires them.
  6. Kamishibai intelligently examines current network stability and uses the cached fragment or requests a new one from the server accordingly.
  7. Kamishibai interprets the URL and makes suitable Ajax requests to generate the page.
  8. Kamishibai intelligently discovers and fragments that are currently missing and requests them from the server.
  9. We think that explicit syncing sucks. Kamishibai will make syncing almost invisible to the end user.
  10. Kamishibai works offline.
  11. Kamishibai does not enforce a specific UI design and does not come with widgets. Designers are expected to be capable of coding their own widgets with HTML and CSS. This makes design extremely flexible so you can easily brand you website.

Why isn’t Kamishibai Javascript MVC?

  1. Ruby and Ruby-on-Rails are superb. There’s a huge amount of functionality that you will miss with current Javascript MVC frameworks.
  2. Javascript MVC frameworks typically require a lot of Javascript on the browser. This will make first load times for mobile devices extremely slow (seconds for Javascript MVC vs tenths of seconds for Kamishibai).
  3. Rendering HTML on mobile devices will always be slower than on powerful server hardware. Furthermore, pages rendered on the server will be cached for later use, making it even faster.
  4. If the server is slow, you can simply add more hardware. You can’t do that with client side libraries. You are always limited by whatever cheap and slow hardware the customer choses.
  5. Javascript MVC requires a steep learning curve. On the other hand, Kamishibai only requires a few extensions onto HTML, CSS. You don’t even need to learn Javascript to get started. You can easily convert preexisting websites, and even WordPress sites.