3 Tools To Help You Optimize Your PhoneGap App’s Performance

Create a Better User Experience for Cross-Platform Mobile Apps

Mobile Apps, Mobile Development, User Experience Comments (2)

What do you do when your PhoneGap app is running slow and you don’t know why?

It’s a problem that faces every mobile developer—your application has slowed down and is eventually brought to its knees.

But why? You’ve kept in mind all of the basic principles in creating a better PhoneGap app, but you’re still not getting the user experience you want. You think to yourself that your application is not that complicated. Surely if games like Infinity Blade III can run smooth as butter, then there’s no reason why your simple sliding animation can’t run just as well.

So what do you do? Start poking and prodding and guessing and checking? Maybe.

But before you start with that, let’s get out some of our tools and measure our application.

Measuring is an important principle—it’s one that I’ll be covering in my upcoming talk at DevLearn about Developing Better PhoneGap Applications.

A huge part of building a successful application is measuring where you’re currently at. This seems obvious when it comes to usage analytics, but it’s just as important when focusing on user experience.

There are a number of tools available to us to assist in measuring our application and highlighting problems.

Measuring CPU Usage

The time the CPU spends tending to your application is time that it cannot spend listening to the user.

By default, the JavaScript in your application is going to do its work on the same thread that handles user interaction. We could attempt to offload this functionality by using a plugin to use a background thread/queue, but before we go through that work, let’s make sure we’ve done our due diligence in ensuring the CPU is not doing more work than we expect.

As of Xcode 5, Apple has provided a really useful set of debugging tools that give us an overview of the current usage of system resources, including CPU usage. Since these are available anytime you debug on the device, it would be a good practice to get into the habit of simply monitoring these meters each time you debug on the device (which should be frequently).


These are high-level overviews of what’s going on. They are intended to give quick indications of new problems that may have risen during development. Let’s say after implementing a new feature, you notice a pattern like the following:


Over time, the CPU usage of the application continues to rise and remains consumed even when the application should just be waiting for user interaction. This alone doesn’t tell us anything beyond that the CPU is busy when we expected it to be idle. Off hand, we know that a burdened CPU could be the result of a few things:

  1. Perhaps some JavaScript code is stuck in an execution loop.

  2. Perhaps the rendering engine is having to do a lot of calculation and layout work (“reflow”) or painting when it doesn’t need to be.

Using Safari’s Remote Web Inspector

Safari has a remote Web inspector that can attach to a WebKit process running on a connected iOS device and give us valuable insight into what’s going on beneath the hood. This requires a little bit of setup get started.

Note: If your device isn’t appearing in the Develop menu, try quitting and relaunching Safari.

Head to the third tab in the inspector and you’ll be able to enable the timeline tool to inspect the amount of time spent performing network requests, layout and rendering, or executing JavaScript.


Typically, you should see a pattern that follows something like this:


As the user interacts with your application (events shown in yellow), it will likely require the interface to respond in someway, triggering new layout and rendering events (shown in purple). The table below the timeline shows what layout work is actually being down by the browser. The large white spaces indicate time that the Web view sat idle waiting for user interaction.

But let’s say you see a pattern that resembles something like this:


After some user interaction, your application continues to do a lot of layout and rendering work, even 10 seconds after the user has finished interacting with the application.

Depending on your application, this may be expected (perhaps it’s running through an animation sequence).

Maybe it comes as a surprise to you. If you’re in a state in your application where you expect it to be sitting idle and you see a pattern like this, then you know that something is up. Perhaps you already have an idea as to what’s going on. In which case, great! Now you’ve isolated the issue to unneeded layout and rendering work and can begin making changes in your code, all the while remeasuring to test your hypothesis.

You might still be unsure as to exactly what section of code is misbehaving. So let’s cover one last tool.

Using the JavaScript Profiler

Unfortunately, the JavaScript profiler does not run on the device using the remote inspector (not yet, anyway).

However, you still can get really useful information running the app in Safari on your computer (think of your computer as the “best case scenario”—if a problem shows up there, then it will definitely show up on the device).

Just below the timeline tool, you can start the JavaScript profiler. (There’s also a CSS selector profile, but we won’t be covering that.)


Note: Be sure to close out of all other tabs before profiling as it seems to catch JavaScript from every open window and tab (e.g., Gmail or Facebook).

You should focus on just one problem at a time. Run a number of actions that lead up to the problem.

Once you stop the profiler, it’s going to give you a glimpse into the actual functions and lines of JavaScript that are taking the most time to complete.


You’ll want to start by focusing on the items with the highest amount of time, and especially be keeping an eye out for your own code to show up.

If you’re using a JS library (like jQuery or Zepto), you’ll likely see it appear a number of times, and often near the top. This is not (necessarily) because it’s running slowly, but because your code is probably making a number of calls to that library. Focus on your own code for now.

The “Self” column indicates the amount of time actually spent within the function. The total time indicates the amount of time spent evaluating the entire function, including calls it made to other functions.

As you dig down, you may start to find lines of your code that are taking up a lot of total time—functions that perhaps you did not expect to be so time-consuming.


And here is where we begin debugging our application. What changes if we skip calls to this function entirely? What specific pieces of this function are taking the most time, and how can we mitigate that?

You can even set breakpoints to stop execution within a given function to get an in-depth view of the execution path at that point. In fact, these breakpoints even work during remote debugging on the actual device.


Bringing it All Together

In all of this, we’re striving for the best user experience possible. The work we’re doing here is no different than the development and debugging process of a native application (and why should it be?). The goal is measuring is to save time spent guessing and checking so we can more precisely pinpoint problems when they exist.

Again, measuring is only one of many important steps in developing a better PhoneGap application.

If you’re interested in getting an overview of the others, be sure to check out my session at DevLearn, Friday morning at 8:30 a.m. Hope to see you there!

Follow Float
The following two tabs change content below.

» Mobile Apps, Mobile Development, User Experience » 3 Tools To Help You...
On October 15, 2013
, , ,

2 Responses to 3 Tools To Help You Optimize Your PhoneGap App’s Performance

  1. […] Float’s lead developer shows to create a better user experience for your PhoneGap apps by measuring CPU usage, as well as using Safari’s remote Web inspector and the JavaScript profiler. …read more […]

  2. […] you found any other helpful tips? Have any questions about other ways we optimized our PhoneGap apps? We’d love to hear how this has helped you while writing your PhoneGap […]

Leave a Reply

Your email address will not be published. Required fields are marked *

« »